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The  Joint  Systems/Software  Engineering  Environment  (JOSEE) 
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Abstract  Overview 

We  can  define  Systems/Software  Engineering  Environments  (S/SEEs)  as  being  “A  set  of  software- 
based  tools  that  aid  in  providing  total  integrated  lifecycle  support  for  systems  and  software 
development,  augment  all  test  activities  and  aid  in  the  management  of  projects  and  programs.”  In 
other  words,  an  integrated  series  of  software  programs  that  provide  partial  or  total  automation  of  the 
activities  within  system  and  software  lifecycles. 

Ideally,  a  S/SEE  would  be  convenient  to  use,  support  customization  of  data  and  integrated  toolsets, 
have  an  open  architecture,  support  the  selected  software  development  process  methodologies, 
encompass  the  entire  database  while  providing  tool  interfacing  and  evolution  and  support  standards 
which  enable  portability  and  interoperability. 

S/SEEs,  though  a  “hot  topic”,  are  a  fairly  new  idea  in  software  development.  Until  recently,  when 
computer-aided  software  development  was  thought  of,  one  would  think  of  individual  Computer 
Aided  Software  Engineering  (CASE)  development  tools.  One  tool,  one  lifecycle  phase.  Only  since 
the  late-1980’s  has  the  idea  of  a  fully  integrated  S/SEE  been  discussed  or  proposed-by  vendors  and 
users  alike. 

Lockheed  Martin  Aeronautical  Systems  (LMAS)  S/SEE:  JOSEE 

At  Lockheed  Martin  Aeronautical  Systems  (LMAS),  we  have  evolved  our  software  development 
process  from  the  primitive  end  of  the  software  development  lifecycle-no  tool  automation,  to  the 
more  sophisticated  individual  CASE  tools,  both  upper-CASE  and  lower-CASE,  and  onward  to 
partially  integrated  S/SEEs. 

LMAS  has  developed  a  concept,  the  Joint  S/SEE,  or  JOSEE,  that  is  a  process-centered  automated 
workflow  environment  which  combines  the  framework  technologies  and  components  from  several 
CASE  tool  and  S/SEE  technology  vendors.  The  “J”  in  the  acronym  “JOSEE”  stands  for  both  the 
“joint”  cooperation  and  integration  of  S/SEE  vendors  and  CASE  tool  vendors  into  a  common 
technology  based  framework,  and  for  the  “joint”  cooperation  between  several  different  Lockheed 
Martin  companies  which  support  the  concept  of  a  common,  open,  integrated,  heterogeneous  S/SEE. 

The  following  paragraphs  discuss  the  requirements,  vision,  capabilities,  management  and  process- 
methods-tools  integration  of  the  JOSEE. 
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The  JOSEE  vision  includes  providing  an  affordable,  consistent,  real-time  view  of  the  software 
development  process.  This  ensures  that  the  software  manager  and  project  manager  perform  pro¬ 
active  rather  than  re-active  software  management.  The  process  instantiation  and  sophisticated 
metrics  provisions  and  integrated  software  management  capabilities  make  the  JOSEE  solution 
attractive  to  managers  and  developers  alike  at  LMAS. 

The  JOSEE  goal  is  to  reduce  the  cost  of  software  by  providing  automated  means  to  perform 
previously  manual  activities,  and  to  provide  management  with  a  sophisticated  method  of  tracking 
software  project  status. 


The  JOSEE  Common  Framework 

The  JOSEE  is  based  upon  open  industry  standards  and  technologies.  The  JOSEE  framework 
consists  of  the  Digital  Equipment  Corporation  COHESION  product  front-end  and  desktop.  This 
S/SEE  framework  product  supports  the  Common  Object  Request  Broker  Architecture  (CORBA) 
framework  technology  and  also  provides  support  for  the  Open  Software  Foundation  (OSF) 
Distributed  Computing  Environment  (DCE)  middleware.  These  technologies  provide  a  means  for 
support  of  distributed  tooling,  licensing  and  databases  and  support  for  client/server  technologies 
providing  access  to  over  21  platforms. 


JOSEE;  Joint  LMAS/LTASS/SEE 
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Figure  1  -  The  JOSEE  Solution 
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The  COHESION  desktop  is  a  Motif-compliant  desktop  which  provides  a  common  “look  and  feel” 
for  the  desktop  across  all  platforms  for  which  it  can  be  displayed. 

Figure  1  shows  the  capabilities  and  their  associated  solution  sets  for  the  JOSEE. 

LMAS  JOSEE:  Automated  Process  Support 

The  JOSEE  utilizes  Computer  Resources  International’s  (CRI)  Life*FLOW  workflow  automation 
tool  to  instantiate  the  LMAS  Standard  Software  Process  (SSP)  in  an  automated  fashion  which  is 
invisible  to  the  user/developer.  The  LMAS  SSP  is  based  upon  ISO  12207  and  incorporates 
attributes  from  ISO  9000-3,  DO/178-B  and  the  Software  Engineering  Institute’s  (SEI)  Capability 
Maturity  Model  (CMM) .  The  Life*FLOW  instantiation  provides  integrated  tooling  automation  for 
all  areas  of  the  software  development  effort.  Examples  include  automated  peer  review  notification 
and  automated  metrics  collection. 

The  JOSEE  SSP  is  modeled  using  the  IDEFO  notation  and  tool  suite.  The  COHESION  desktop 
allows  for  browsing  of  this  model  using  the  Netscape  Navigator  Version  2.0.  The  IDEFO  models 
are  linked  to  the  actual  Life*FLOW  instantiated  process  using  the  Netscape  Navigator  and  JAVA 
technologies.  From  within  COHESION  a  user  may  browse  the  SSP  on  the  JOSEE  home  page  and 
link  up  with  more  sophisticated  on-line  help  and  process  assets.  As  an  example,  a  user  may  wish  to 
view  the  requirements  management  process  in  IDEFO,  then  drill  down  to  the  Life*FLOW 
instantiation  inside  the  JOSEE  workflow  automation  tool,  view  some  data  using  the  Requirements 
Traceability  Matrix  (RTM)  tool,  and  finally  “hot-link”  to  the  LMAS  SEPD  home  page  which 
contains  the  on-line  policies/procedures  and  “how-to”  guidebooks  for  requirements  management. 
In  summary,  with  a  few  mouse  clicks,  a  user  can  get  on-line  tools  help,  process  help  and  LMAS 
policies  and  procedures  and  view  assets  without  ever  having  to  leave  his/her  personal  computer  or 
workstation. 


3 


Figure  2  shows  the  relationship  between  the  JOSEE  process  modeling  capabilities  and  the  process 
instantiation  inside  the  JOSEE  and  its  subsequent  display  on  the  Software  Project  Control  Panel 
(SPCP),  which  is  described  in  the  following  paragraphs. 


Figure  3  -  The  Software  Project  Control  Panel 

LMAS  JOSEE:  Integrated  Software  Management 

The  LMAS  JOSEE  includes  an  integrated  software  management  system  designed  around  the 
Software  Project  Control  Panel  (SPCP),  as  shown  in  Figure  3.  The  SPCP  provides  a  graphical  user 
interface  (GUI)  view  into  the  current  state  of  the  software  development  project.  The  view  of  the 
SPCP  provided  to  the  user  is  linked  to  the  Life*FLOW  defined  user  role,  such  as  developer, 
manager,  quality  assurance  (QA)  or  vice  president  of  engineering.  The  SPCP  is  flexible  enough  to 
be  customized  by  each  user,  or  according  to  a  project  defined  ruleset.  The  SPCP  GUI  provides  a 
palette  of  gauges  which  are  “point  and  click”  accessible  for  each  user  to  customize  his/her  own 
SPCP  for  their  desired  personal  view.  Each  gauge  represents  a  process  or  product  metric  inside  an 
LMAS  developed  metrics  repository.  This  metrics  repository  provides  an  open  application 
programming  interface  (API)  to  enable  other  third  party  CASE  tools  to  insert  data  for  display  onto 
an  appropriate  gauge  on  the  SPCP.  As  an  example,  the  Requirements  Traceability  Matrix  (RTM) 
Tool  from  GEC-Marconi  can  provide  requirements  database  information  the  LMAS  metrics 
repository  via  a  SQL-Net  interface  between  the  RTM  Oracle  database  and  the  LMAS  Oracle 
metrics  repository. 
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Figure  4 


LMAS  JOSEE:  An  Integrated  Program  Support  Environment 

The  LMAS  JOSEE  provides  an  integrated  approach  to  a  S/SEE.  It  utilizes  the  “best  of  the  industry” 
for  the  four  major  components  in  the  S/SEE:  (1)  Desktop  Presentation  Integration,  (2)  Process 
Integration,  (3)  Database  Integration,  and  (4)  Messaging  Integration.  The  desktop  and  messaging 
integration  are  provided  by  the  Digital  Equipment  Corporation  COHESION  product.  The  process 
integration  and  the  database  integration  are  provided  by  the  CRI  Life*FLOW  and  Life*CYCLE 
tools.  LMAS  has  provided  its  own  custom  capabilities  to  tie  these  two  product  suites  together  into  a 
process-centered,  automation-based  management  tool  by  including  the  metrics  Oracle  based  metrics 
repository  which  provides  the  capability  to  link  the  databases  of  the  various  tools  for  metrics 
presentation  on  the  SPCP. 

Conclusion 

The  JOSEE  solution  provides  a  “state  of  the  art”  implementation  of  “state  of  the  practice”  tooling 
and  S/SEE  framework  technologies.  Figure  5  shows  the  evolution  of  the  S/SEE  industry  and  the 
future  of  the  JOSEE  concept  and  vision.  The  ultimate  goal  remains  creating  an  integrated 
development  environment  for  hardware  and  software  technologies,  such  as  VHDL  and  Ada. 
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Figure  5  -  The  Evolution  of  LMAS  Environment 
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Abstract 

The  recently  approved  VITAL  [7]  standard  will  pennit  many  of  the  drawbacks 
presented  by  the  use  of  VHDL  at  gate  level  to  be  overcome.  It  does  not,  however,  address 
one  of  the  basic  problems  at  gate  level:  cuirent  modeling. 

The  main  puipose  of  the  present  work  is  to  propose  a  cunent  modeling  for  VHDL 
gate-level  descriptions  which  are  VITAL  compliant.  This  technique  will  be  applied  to 
different  areas,  such  as  low  power  design,  BIST  .scheduling  and  fault  simulation,  for 
cuiTent  fault  modeling  and  for  power  estimation  and  average/peak  ciurent  detennination 
with  a  maximum  variation  of  10%  with  respect  to  the  data  obtained  by  SPICE  LEVEL 
3[1].  Logically,  the  new  types,  signals  and  subprograms  used  in  ciuTent  modeling  do  not 
verify  the  modeling  rules  of  the  recently  approved  VITAL  standard,  constituting  a 
proposal  for  a  possible  extension  in  the  future. 

The  order  of  contents  of  this  paper  will  be  as  follows.  In  the  next  section  the  concepts 
necessary  for  transitory  cuiTent  modeling  will  be  introduced.  Then,  an  example  of  the 
application  of  this  technique  will  be  presented.  Tlie  final  section  will  present  the 
conclusions  of  the  article. 


1.-  Current  modeling 

With  the  aim  of  developing  cuirent  models  fiir  VITAL  cells  some  non- VITAL  standard 
types  and  subprograms  have  been  introduced. 


In  order  to  be  able  to  define  a  cuirent  modeling  in  VITAL,  it  is  nece.ssai"y  to  model  the 
cuirent  flowing  from  the  cii'cuit  to  the  sensor  or  power  supply  in  a  continuous  form. 


considering  all  behavior  to  be  transitory.  This  is  not  possible  using  an  event-driven 
simulator.  For  this  reason,  the  current  wavelorm  has  been  modeled  by  means  ot  a  piece- 
wise  linear  current  waveform  (figure  1),  in  a  similar  way  to  [ij[2][3].  This  enables  results 
to  be  obtained  which  are  in  disagreement  with,  at  most,  lO'-T  ot  those  obtained  with 
SPICE  [1],  The  basic  idea  is  that  the  cunent  wavefomis  for  any  change  in  the  inputs  of 
the  VITAL  cell  are  modeled  by  the  foundry  as  a  set  of  time-cuirent  pairs  (figure  2). 


The  VHDL  simulator  must  be  able  to  add  up  all  of  these  piece-wise  linear  cunent 
waveforms  to  obtain  the  total  cunent  waveform.  Tire  new  approach  introduced  in  this 
paper  is  that  the  VHDL  simulator  does  not  work  with  current  values,  but  rather  with  the 
points  at  which  the  slope  of  the  wavefonn  varies  (break  points).  In  this  way,  the  total 
wavefoiTn  can  be  calculated  with  great  speed  and  accuracy  (Figure  3). 


9 


In  our  approach,  the  list  of  pairs  presented  previously 
equations  as  follows  ; 

Input  change  =>  Current  =  P,  T  +  C, 

P3  *  T  +  C, 

Pn  *t  +  c^ 


is  iransh)rmed  into  a  set  of  linear 


t„<T  <ti 
t,  <  T  <  p 

In-l  <  T  <  t, 


Where; 


T  =  Continues  Time 

c,=c.-(P,*t.,) 


The  cuiTent  is  modeled  in  VHDL  hy  means  of  resolved  signals  of  record  type 
(Dcuii'ent)  in  which  one  field  models  the  parameter  P  (slope)  and  the  other  the  parameter 
C  (initial  point)  of  the  linear  equation. 


type  cuirent  is  record 
P  ;  REAL; 

C  ;  REAL; 
end  record; 

type  CurrentAnay  is  ;uTay(  NATURAL  nuige  <>)  of  eunent; 
function  DyntunicPowerSouiceC  A  :  CuirentAnay  )  return  current; 

_ subtype  Dcurrent  is  DynmnicPowerSource  eunent; 

Thus,  the  calculation  of  the  total  cuiTent  is  defined  as  the  sum  of  the  cuments  of  each 
cell.  These  are  modeled  by  means  of  equations  of  the  following  equation  type,  in  which 
(P,  C)  vary  as  discrete  events. 

Cellj_current  =  Pj*  Time  +  Cj 

Hence,  the  total  current  is  calculated  by  means  of  the  following  expression  ; 

Total_cuiTent  =  Z  Celli_current  =  (X  P. )  *  Time  +  (X  C^) 

This  equation  is  implemented  in  the  resolution  function  of  the  DcuiTent  type.  Thus,  this 
will  be  the  type  of  signal  used  to  model  the  power  source. 

function  Dyn;unicPower,Source(  A  ;  CurrentAnay  )  return  eunent  is 
vmiable  result  :  current  :=  (0.0 . 0.0); 
begin 

IF(  A'LEN(;;TH=1)  THEN  retuniC  A(A'L(  )W));  ELSE 
for  i  in  A'RANGE  loop 

result, P  :=  result. P  +  A(i).P; 
result. C  :=  result. C  +  A(i).C; 

end  loop; 

END  IF; 
return  result; 

end;  _ 


Tlie  advantage  of  this  type  is  that  it  allows  the  current  waveform  to  be  modeled  with 
relative  accuracy.  From  the  point  ol  view  ot  VITAL,  a  new  port  (  ot  the  Dcun'cnt  type)  is 
introduced  in  the  cells  which  models  the  dynamic  current  consumption  ot  the  cell.  Also,  a 
generic  port  is  added,  enabling  the  {time-P-C}  sets  to  he  specified  by  means  of  the 
VitalCuixentTableType  type.  Every  row  of  this  table  is  associated  to  the  transaction 
modeled  in  the  same  row  of  a  VitalStateTableType  constant.  These  tables  are  proces,sed 
in.side  the  cell  by  means  of  a  VitalDynamicCuiTcnt  subprogram.  Tlie  types  necessary  for 
the  simulation  and  the  VitalDynamicCurrent  subprogram  are  shown  below: 

type  VitalCurrent  is  record 
Point  :  cunent; 

T  :  TIME; 
end  record; 

type  VitalCunentTableType  is  anayCNATt  IRAL  range  <>, NATURAL  nnige  <>)  of  VitrdCunent; 
procedure  VitalDyiicUnicCunent  (  construit  CunenlTable  :  in  VittdC’uiTentTableType; 

constant  StateTable  :  in  VitalStateTableType; 

•signtil  Dtittiin  :  in  sld_logic_vector; 
signal  Result  ;  out  current  )  is 

constant  InputSize  :  INTE(.iER:=  Dataln'LENCi  fH: 
vtuiable  DatalnAlias :  std_logic_vector(n  to  InputSize  -1); 

vai'iable  StateTableAlias  :  VitalStateTableType(()  TO  (StateTable'LENGTH(I)-I), 

0  TO  (StateTable'LENGTH(2)-I))  :=  StateTable; 
vtuiable  CunentTableAlias:  VitalCunentT;ibleType(()  TO  (CurrentTable'LENGTH(I)-l), 

0  TO  (CunenlT;ible'LENGTH(2)-I))  ;=  CunentTable; 
type  EventCunentTableType  is  tmay  (Natural  range  <>)  of  VitalCuirent; 
variable  EventCurrentTable  :  EventCurrentTtiblel  ype{  0 1  ( )  (StateTable LENGTH(l)-l)); 
vmiable  maxEventIndex  :  Natural  :=  0: 
vtu'iable  nextEventIndex  :  Ntitunil  :=  0; 
vmiable  Index :  INTEGER; 
vmiable  cunentTime  :  TIME; 
vmiable  nextTiine  :  TIME  :=  TIME'l  II(.iH; 
vmiable  uextEvent:  TIME; 
vmiable  PrevTime :  TIME; 
vmiable  temp :  cunent; 

vmiable  PrevDataIn  ;  Std_logic_vector(()  to  l)ataIn'LENGTH-l):=  (others=>'X'); 
begin 

infinite:  LOOP  -  Infinite  loop 

if(maxEventIndex  /=  nextEventIndex)  then 
wait  on  Dattiin  for  nexlEveut; 

else 

wait  on  D;it;un; 

end  if; 

DakdnAlias;=  To_X()l(D;itatn); 
currentTiine  :==  now. 
if(DataInAli;Ls/=PrevDatain)  tlien 

if(NextEvent  /=  TIME'HIGH  mid  nextEventIndex  <  maxEventIndex)  tlien 
if(nextTiine  >  cunentTime)  tlien 

NextEvent  :=  nextTiine  -  currentTiine; 

else 

assert  false  _ _ _ 
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report  "Time  computiilion  error  in  VitalDyiininicC'urreiil"; 

end  if; 
end  if; 

assei1(  StateTable'LENGTlI(l)=CuiTent'rable'I,nN(rrM(  I )) 
report  "Inconect  cunent  table"; 
coljoop;  FOR  i  IN  StateTahleAlias’RANCiEf  I )  L( )( )P 
-  Check  each  input  element  of  tlie  entry 
rowjoop;  FOR  j  IN  0  TO  InputSizc  LOOP 
IF  (j  =  inputSize)  THEN  —  This  entry  matches 
nextEventIndex;=0; 
maxEventIndex;=(); 
nextTime;=cunentTime; 

PrevTime;=  0  ns; 

currentjoop;  for  k  in  0  to  (CuiTetitT;ible'LENCTTH(2)-I)  LOOP 
EventCunentT;ible(maxEventIndex).point,A  ;= 
CurrentTableAlias(i,k),point.A; 
EventCurrentTablefmitxE ventindex). point. B  ;= 

CurrentTable Alias(i,k). point. B  - 
(CurrentTableAlias(i,k).point.A 

’''(TimeToReal(cunentTime)+  TiineToRe£il(PievTime))); 
EventCunentTiiblefmaxEventlndexI.T  ;=  CunentTable(i,k).T; 
imrxEventlndex  ;=  m;ixEventIndex  +1; 
if(('uiTenfr;ible(i,k).T  =  TIME'HKtH)  llien 
exit  currentjoop; 

else 

PrevTime;=  ("urreulTahleAliasfi.kl.T  +  PrevTime; 

end  if; 

end  loop  curreut_loop; 
exit  coljoop; 
end  if; 

exit  rowjoop  when  not 

StateTableM;itch(PrevDataln(j),  DatalnAlias(J),  St;iteTableAlias(i,j)); 
end  LOOP  row_loop; 
end  LOOP  coLloop; 

PrevDataIn  ;=  DatalnAlias; 

end  if; 

if(nextTime=cmTentTime  tind  mtixEventIndcx  >  nextlEventlndex)  tlien  -  update  events 
temp. A  ;=  EventCunentTable(nextEventIndex).point.A; 
temp.B  ;=  EventCuiTentT;ible( nexfEventlndex). point. B; 
if(EventCuiTentTtible(nexlEventIndex).T  =  TIME'HIGH)  tlien 
nextTime  ;=  TIME'HIGH; 
uextEvent;=  TIME'HIGH; 

else 

nextTime  ;=  EvenlCurrentTable(ncxlEventIndex).T  +  cunentTime; 
nextEvent;=  EventGunenlTable(ncxtEvcntIndex).T; 

end  if; 

nexfEventlndex  ;=  NextEventlndex  +1; 

Result  <=  temp; 

end  if; 
end  LOOP  ; 

end;  _ 
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2.-  Example  of  current  modeling 


As  an  example  of  cuirent  modeling,  the  model  ot  current  How  at  a  two-input  AND  gate 
is  proposed.  For  this,  it  will  be  necessary  to  define  a  set  ol  parameters  C,  (slope  i),P, 
(initial  point  I)  and  f  (time  between  two  changes  of  the  cunent  flow).  These  parameters 
are  defined  by  the  VitalCun-entTableType  type  generic  port.  Each  row  is  associated  to  a 
transition  of  the  VitalTruthTableType  type  generic  port.  In  this  way,  when  an  input  of  the 
AND  gate  changes  from  ‘0’  to  ‘1 ’(symbol  7'),  the  output  being  ‘O’,  the  form  of  the 
cuiTent  will  be  given  by  the  following  pairs; 


[0,0  A],[500ps,  10  mA],  [1000  ps,  -1mA],  [1200  p; 

s,  0  A] 

entity  and2  is 

'0'), 

-  1 

generic!  InputTnuisition  :  VitalStatel’ableType(  0  to  3,  0  to  2):=(  ( 

(  T, 

'0'), 

-2 

(  'B'. 

'B', 

'r'). 

-  3 

(  'B'. 

B', 

T)); 

-4 

CunentWiivelbim  :  VitalCiinentTableTypet  0  to  3,  0  to  3):=( 

(  ((2.0e7,0.0),  .300  p.s),  ((-2.2e7, l().()c-3),  .300  ps  ).  ((.S.()e6,-l.()e-3),  200  ps),  ((0.0,20.0e-9), 
TME’HIGH)),  -T 

( ((2.0e7,0.0).  500  ps),  ((-2.2e7,10.0e-3),  .300  ps  ).  ((.3.0e6,-1.0e-3),  200  p.s),  ((0.0,20.0e-9), 
TIME'HIGH)),  --2 

( ((1.0e6,0.0),  1  ns),  ((0.0, l.Oe-3), TIME'HIGH), ((0.0,0.0),0  ns),((0.0,().()),0  ns)),  -3 

( ((1.0e6,0.0),  1  ns),  ((().(), l.()e-3),TIME'HIGH),((().0,0.0),0  ns),((0.0,0.()),0  ns))  )  -4 

); 

port(  InA,Inb  :  in  SttLlngic; 

Y  :  MDut  Stdjogic; 

vdcl:  Out  Dcunent  :=  (O.O.O.O)); 

end  ;  _  _ 


3.-  Conclusions 

In  this  paper  a  cuiTent  model  has  been  presented  lor  VHDL  structural  descriptions 
which  follow  the  rules  laid  down  by  the  VITAL  standard.  For  this,  it  has  been  necessary 
to  define  types  and  subprograms  which  model  the  curretit  How  in  the  cell.  These  elements 
have  not  been  introduced  in  the  VITAL  standard. 

On  tire  other  hand,  the  simulator  results  seem  to  show  little  discrepancy  compared  to 
those  obtained  with  electrical  simulators  like  SPICE[1].  This  permits  the  current  modeling 
and  the  application  of  IDDQ[4]  and  IDDT[5]  to  test  circuits  (main  application  of  the 
proposed  techniques).  As  a  consequence  of  the  application  of  the  models  presented  here 
to  fault  simulation,  better  results  have  been  achieved  than  those  obtained  by  some  non- 
VHDL  commercial  logic  simulators  [6],  since: 

1.-  It  enables  the  separate  parts  of  the  circuit  under  test  to  be  modeled,  since  as 
many  Dcurrent  type  signal  can  be  used  as  there  are  sepai'ate  power-supply  parts 
of  the  circuit. 

2  -  It  enables  the  maxiiuum  value  of  the  static  and  dynamic  current  in  the  fault 
free  circuit  to  be  estimated,  thus  facilitating  the  design  of  the  current  sensor.  In 
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fact,  the  sensor  could  be  incorporalcd  as  a  Vila!  Level  0  cell  in  the  system 
description. 

3.-  Tlie  cuiTent  modeling  is  tool  independeni  because  the  cuiTent  behavior  is 
defined  in  the  VITAL  library.  Thus,  the  modeling  is  very  flexible  and  portable. 

At  the  moment  effort  is  being  made  in  two  lines  of  development.  On  one  hand,  to 
improve  the  modeling  in  the  case  where  a  signal  changes  while  the  port  is  still  affected  by 
a  previous  change,  and  on  the  other  hand,  to  study  the  propagation  of  'X'-values  through 
the  circuit. 
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Abstract 

Codesign  is  a  unified  methodology  to  develop  complex  systems  with  hardware  and 
software  components.  EDgAR,  a  platform  for  hardware/software  codesign  is  de¬ 
scribed,  which  is  intended  to  prototype  complex  digital  systems.  It  employs  pro¬ 
grammable  logic  devices  (MACHs  and  FPGAs)  and  a  transputer-based  parallel  ar¬ 
chitecture.  This  platform  and  its  associated  methodology  reduce  the  systems  pro¬ 
duction  cost,  decreasing  the  time  for  the  design  and  the  test  of  the  prototypes.  The 
EDgAR  supporting  tools  are  introduced,  which  were  conceived  to  specify  systems 
at  an  high-level  of  abstraction,  with  a  standard  language  and  to  allow  a  high  de¬ 
gree  of  automation  on  the  synthesis  process.  This  platform  was  used  to  emulate  an 
integrated  circuit  for  image  processing  purposes. 

Keywords:  codesign,  rapid  system  prototyping,  FPLDs,  transputer. 


1  Introduction 

All  the  platforms  used  in  codesign  are  not  universal,  in  the  sense  that  not  all  the 
systems  can  be  implemented  in  a  straightforward  way.  Additionally,  those  platforms 
are  generally  too  expensive,  since  they  have  a  large  number  of  hardware  resources. 
If  these  resources  are  not  completely  used  for  a  significant  number  of  systems,  the 
ratio  performance/cost  is  extremely  low. 

The  EDgAR  [Emulador  Digital  Altamente  Reprogramvel)  platform  was  designed 
to  achieve  a  high  performance/cost  ratio  and  to  implement  complex  systems  with 
critical  time  constraints,  used  in  real-time  applications  (especially  computer  vision 
systems).  However,  the  platform  design  was  not  significantly  constrained  by  the 
particular  aspects  of  these  systems. 


EDgAR  is  a  FPGA-based  platform  that  includes  a  transputer  that  can  be  linked  to 
a  parallel  architecture.  With  the  EDgAR  platform,  prototypes  of  complex  digital 
systems  can  be  obtained  in  a  short  period  of  time. 

The  recent  development  on  the  area  of  re-programmable  components  (FPLDs  -  Field 
Programmable  Logic  Devices)  made  them  attractive  to  fast  and  efficiently  create 
prototypes,  because  their  complexity  can  achieve  tens  of  thousands  of  equivalent 
logic  gates,  and  the  manufactures  provide  electronic  CAD  tools  to  support  those 
components.  Since  the  time  of  design  and  the  production  cost  were  reduced,  and 
the  FPLDs  need  no  longer  to  be  removed  for  programming,  they  can  be  used  with 
success  in  codesign  platforms. 

The  transputer  is  a  microprocessor  with  communication  and  processing  power  and 
a  simple  interface.  It  allows  the  scale  of  parallelism,  due  to  its  capacity  to  be 
interconnected  with  other  identical  microprocessors. 

Codesign  is  closely  related  to  the  design  of  systems  with  unreachable  performance 
in  software  implementations,  and  systems  with  higher  complexity  than  those  imple¬ 
mented  in  hardware  (ASICs)  [1,  2]. 

This  article  is  organised  as  follows.  In  section  2,  the  architecture  of  the  EDgAR 
platform  is  described.  The  synthesis  of  digital  systems  with  EDgAR  is  analysed  in 
section  3,  with  comments  to  the  different  phases  of  the  process:  the  system  specifi¬ 
cation,  the  hardware/software  partitioning,  the  allocation  of  platform  resources  to 
partitions,  and  the  validation  of  the  prototype  obtained.  In  section  4  the  emulation 
of  a  VLSI  circuit,  the  CLiTCH,  on  EDgAR  is  presented. 


2  The  architecture  of  the  EDgAR  platform 

The  structure  of  the  EDgAR  platform  (figure  1)  is  supported  by  two  major  blocks: 


i)  a  digital  information  processing  unit  (UPDI),  that  implements  a  parallel  com¬ 
putation  node,  with  communication  and  scalar  processing  power,  and  where 
the  digital  signals  processing  speed  is  not  crucial; 

ii)  a  programmable  logic  unit  (ULP),  containing  a  great  amount  of  reconfigurable 
resources  and  whose  operation  speed  is  close  to  that  of  the  circuits  with  fast 
technologies  available  on  the  market,  allowing  better  performances  than  those 
obtained  with  traditional  simulators. 


To  carry  out  the  UPDI,  the  transputer  (a  microprocessor  with  communication  and 
processing  power)  was  selected.  It  allows  the  scale  of  parallelism,  due  to  its  capacity 
to  be  interconnected  with  other  identical  microprocessors,  building  up  a  network 
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with  a  variable  topology.  This  processor  is  also  responsible  for  the  interface  with 
the  prototype  development  system  and  for  the  initial  configuration  of  the  ULP  com¬ 
ponents  [3].  On  the  debugging  phase,  the  user’s  interface  with  the  platform  was 
developed  on  a  unit  containing  several  TRAMs  (TRAnsputer  Modules)  installed  on 
a  PC  and  using  a  C  compiler.  The  connection  between  the  unit  of  TRAMs  and 
EDgAR  is  done  by  one  (or  more)  transputer  link(s),  which  are  asynchronous.  The 
tools  available  to  work  with  the  TRAMs  allow  to  monitor  the  transputers  of  the 
TRAMs  and  EDgAR,  to  compile  the  programs  and  to  load  them  to  the  transputers. 


o 

w 
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Figure  1:  The  architecture  of  the  EDgAR  platform. 

The  ULP  provides  a  large  quantity  of  resources,  without  significantly  compromising 
the  speed  of  the  systems  being  implemented.  The  ULP  structure  is  based  on  two 
types  of  PLDs:  one  appropriated  to  implement  circuits  containing  logic  at  two  levels 
(MACHs  -  Macro  Array  CMOS  High-density),  while  the  other  owning  a  structure 
organised  like  a  matrix,  suitable  to  implement  circuits  containing  multi-level  logic 
(FPGAs  -  Field  Programmable  Gate  Arrays). 

The  present  EDgAR  platform  version  (figure  1)  is  implemented  with  a  T425  trans¬ 
puter  (a  T805  could  also  be  used),  4  Mbytes  of  DRAM,  4  MACHs  and  4  FPGAs. 
The  MACHs  belong  to  the  2x0  AMD  family,  containing  44  pins,  64  macrocells  and 
32  I/O  cells.  The  FPGAs  are  Xilinx  LCAs  that  belong  to  the  3090A  family:  two 
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FPGAs  have  84  pins  and  the  others  have  175  pins.  All  FPGAs  have  320  macrocells 
and  139  I/O  cells. 

All  components  are  connected  to  common  buses,  using  different  addresses  for  the 
transputer  internal  and  external  memories,  and  for  each  of  the  FPGAs  and  MACHs. 
To  emulate  distinct  digital  systems  on  the  platform,  and  to  keep  the  possibility  of 
reconfiguration  by  software,  each  MACH  is  connected  to  the  buses  by  2  address 
lines  and  8  data  lines,  while  each  LCA  uses  4  lines  to  connect  to  the  address  bus 
and  32  lines  to  the  data  bus.  The  remaining  I/O  pins  of  the  MACHs  and  LCAs  are 
available  in  connectors,  allowing  to  emulate  systems  with  different  number  of  I/O 
signals  and  different  size  of  hardware  components.  To  scale  the  processing  power, 
the  transputer  communication  lines  (links)  are  available  outside  the  board.  To  scale 
the  hardware  resources,  the  VME  connector  can  be  used  to  link  the  FPGAs  on 
EDgAR  with  other  platforms  that  also  have  a  VME  bus. 


3  Digital  systems  synthesis  with  EDgAR 

The  development  process  with  the  present  platform  runs  through  several  phases, 
from  the  specification  to  the  implementation,  going  through  the  simulation  and  test 
(figure  2).  Next,  it  is  explained  how  these  phases  are  being  incorporated  on  the 
development  environment  that  will  support  EDgAR. 


3.1  Specification 

On  the  codesign  context,  the  selection  of  a  high-level  environment  for  system  spec¬ 
ification  is  being  considered,  which  will  be  the  basis  of  the  specification  model  to 
be  followed.  The  hypothesis  under  consideration  include  an  FSM-based  representa¬ 
tion,  the  Occam  language,  a  representation  using  Petri  Nets  (PNs)  or  the  VHDL 
language.  A  high  level  formal  representation  is  used  to  prove  the  specification  cor¬ 
rectness  and  to  guarantee  that  this  correctness  is  preserved  in  the  next  design  phases. 

The  modelling  of  systems  with  FSMs  has  two  disadvantages;  (i)  as  a  high-level 
notation,  FSMs  are  not  so  abstract  as  desired,  and  (ii)  FSMs  are  not  appropriate  to 
represent  systems  with  high  algorithmic  complexity  [4]. 

The  Occam  language  presents  the  advantages  of  being  simple,  suitable  for  real-time 
representation,  having  potential  for  parallelism,  a  well  defined  semantics  (based  on 
CSP  [5])  and  the  adequacy  to  represent  components  to  be  implemented  on  the 
transputer  [1].  OCCAM  is  not  a  good  solution,  because  it  is  not  a  widely  used 
language  (this  is  reflected  in  the  reduced  number  of  available  synthesis  tools)  and 
it  has  a  strong  binding  to  the  transputer  processors’  family,  which  means  that  it  is 
not  an  implementation  independent  language. 


4 


5 


PNs  are  a  mathematical  formalism  used  to  model  systems  that  include  concurrent 
activities  and  its  graphical  representation  can  be  used  to  animate  the  modelled  sys¬ 
tems.  The  formalism  associated  with  PNs  allows  the  systems  validation  in  relation 
to  a  set  of  properties:  determinism,  deadlock  freedom,  conflict  freedom,  liveness  and 
boundedness  [6]. 

VHDL  is  a  standard  hardware  description  language  used  to  design  digital  systems, 
allowing  the  model  to  be  clearly  specified,  simulated  and  synthesised.  The  speci¬ 
fications  of  the  systems  designed  with  VHDL  can  be  hierarchically  structured  and 
properly  represented  [7]. 

The  joining  between  VHDL  and  PNs  is  considered  to  be  an  acceptable  solution.  This 
was  studied  and  applied  with  success  in  the  specification  of  parallel  controllers  [8]. 
An  identical  evaluation  is  being  carried  out  on  the  EDgAR  platform,  to  implement 
systems  that  are  more  complex  than  those  already  tested. 

The  specification  model  is  influenced  by  the  fact  that  the  EDgAR  platform  imple¬ 
ments  systems  asynchronously,  since  a  completely  synchronous  specification  model 
is  less  suitable  to  represent  the  aspects  related  to  implementations  in  hardware  and 
software,  which  are  asynchronous  by  nature.  Although  an  independent  implemen¬ 
tation  specification  is  a  goal,  this  is  not  commonly  achieved. 


3.2  Hardware /Software  Partitioning 

The  hardware/software  partitioning,  considered  to  be  the  most  complex  phase  on  the 
codesign  context,  is  a  hard  task  to  be  fully  accomplished  by  an  automatic  process. 
Usually  the  partitioning  algorithm  is  fed  with  inputs  (supplied  by  the  designer)  to 
assist  the  process.  The  partitioning  task  comprises  the  phases  of  assignment  and 
scheduling,  although  some  approaches  use  assignment  only  [9,  10]. 

The  partitioning  applied  in  EDgAR  is  behavioural,  since  it  is  done  on  the  system 
specification.  The  behavioural  partitioning  has  several  advantages  over  the  struc¬ 
tural  partitioning,  but  the  most  relevant  is  the  fact  that  the  impact  of  changes  on 
the  system’s  specification  is  smaller  on  the  first  one  [11]. 

The  approach  used  for  partitioning  belongs  to  the  software-oriented  solutions.  This 
means  that  the  starting  point  is  a  complete  software  implementation,  and  after  parts 
of  the  system  are  moved  to  hardware  based  on  time  criteria. 

The  software  and  hardware  partitions  are  intended  to  have  different  granularities: 
task  level  on  software  partitions  and  block  level  on  hardware  partitions.  Hardware 
partitions  are  implemented  with  the  ULP  in  EDgAR  and  the  software  partitions 
with  the  UPDI.  Among  the  hardware  partitions,  those  implemented  with  MACHs 
must  be  distinguished  from  those  implemented  with  FPGAs. 


6 


The  partitioning  comprises  the  isolation  of  the  parts  with  critical  time  constraints, 
which  will  result  on  hardware  partitions;  the  remaining  parts  may  result  on  software 
partitions.  The  definition  and  implementation  of  the  communication  strategies  and 
interface  between  partitions  is  an  important  aspect  to  be  considered  on  the  partition¬ 
ing  phase.  On  EDgAR,  the  interface  between  two  software  partitions  is  implemented 
with  memory  positions  and  transputer  channels.  Virtual  channels  are  used  if  the 
partitions  are  on  the  same  processor,  while  physical  channels  are  used  if  the  par¬ 
titions  are  on  different  processors.  The  interface  between  two  hardware  partitions 
uses  registers  and  connectors,  and  the  interface  between  a  hardware  and  a  software 
partition  is  implemented  with  the  resources  used  in  the  two  previously  mentioned 
types  of  interface. 


3.3  Synthesis  of  Components 

The  synthesis  of  components  is  divided  in  three  main  parts:  the  synthesis  of  software 
partitions  (left  block  of  figure  2),  the  synthesis  of  hardware  partitions  (central  block) 
and  the  synthesis  of  the  interface  between  partitions  (right  block).  Each  part  can 
be  seen  as  an  allocation  of  resources  that  results  on  a  configuration. 

The  allocation  of  UPDI  resources  to  software  partitions  is  accomplished  in  two 
phases.  In  the  first,  the  high-level  specification  of  these  partitions  is  converted 
into  modules  on  an  intermediate  language  (C).  This  task  requires  the  existence 
of  a  converter  to  C  language,  and  the  generated  C  modules  are  compiled  to  the 
transputer  machine  code. 

The  allocation  of  ULP  resources  to  hardware  partitions  results  in  allocating  to  these 
partitions  resources  available  in  two  types  of  PLDs:  MACHs  and  FPGAs.  The 
decision  about  which  type  of  PLD  to  allocate  to  each  module  is  based  on  the  need 
of  storage  elements  and  the  existence  of  critical  time  constraints.  Partitions  that 
need  a  number  of  storage  elements  higher  than  a  critical  value  are  allocated  to 
FPGAs,  while  partitions  that  require  a  response  faster  than  a  critical  value  are 
allocated  to  MACHs.  If  both  conditions  arise  in  the  same  partition  and  it  can  not 
be  partitioned  again,  several  components  are  allocated  to  this  partition. 

To  configure  the  MACH  devices,  the  compilation  and  the  later  mapping  of  their 
resources  are  completed  with  the  agreement  of  the  hardware  allocation.  The  result 
is  a  JEDEC  file  for  each  allocated  device.  The  hardware  allocated  to  the  FPGAs 
determines  their  configuration.  The  first  step  to  obtain  this  configuration  is  to 
create  an  intermediate  format  file  (netlist)  that  will  be  used  as  input  to  the  Xilinx 
Automatic  CAE  Tools  (XACT).  These  tools  generate  the  binary  configuration  file 
for  each  allocated  FPGA,  defining  the  device  operation,  but  before  they  map,  place, 
and  route  the  specification. 

When  the  system  is  powered  on,  the  transputers  download  the  configuration  files 
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to  the  FPGAs  and  establish  their  operation.  Among  the  available  ways  to  send  the 
configuration  file  to  the  FPGA,  the  peripheral  mode  was  selected,  which  sends  the 
configuration  on  a  byte  basis.  After  the  start-up,  the  FPGA  can  be  reprogrammed 
without  a  physical  reset  of  the  system. 


3.4  Components  Verification 

XACT  allows  for  two  types  of  simulation,  in  order  to  verify  the  parts  of  the  system 
implemented  with  FPGAs:  functional  and  timing  simulations.  The  functional  simu¬ 
lation  detects  logical  errors,  while  the  time  simulation  tests  the  functionality  under 
different  conditions,  like  a  higher  temperature,  a  lower  power  or  a  slower  process. 

The  obtained  prototype  can  be  validated  at  a  higher  level  of  abstraction  in  a  process 
called  co-simulation.  The  co-simulation  is  a  time  consuming  task  that  demands  a 
huge  computation  power.  For  these  reasons,  it  was  intended  to  use  a  simulation 
model  adapted  to  parallel  architectures  [12].  This  advantage  results  because  the  co¬ 
simulation  process  runs  on  part  of  the  same  architecture  that  is  used  to  implement 
the  simulated  prototypes. 


4  The  emulation  of  a  VLSI  circuit  with  EDgAR 

The  emulation  of  the  GLiTCH  chip  [13],  an  associative  processor  array  designed  for 
a  VLSI  circuit  to  apply  on  image  processing,  was  used  as  a  case  study,  to  validate 
the  physical  structure  of  the  EDgAR  platform  and  to  explore  the  capabilities  of  the 
platform  for  codesign  (figure  3). 

The  GLiTCH  is  structured  on  5  blocks:  an  array  of  64  1-bit  processing  elements 
(PEs),  each  one  with  68  bits  of  associative  memory  (CAM),  a  pattern  router  (PEL), 
a  video  shift  register  (VSR)  with  64x8  bits,  and  an  instruction  decoder  [14]. 

The  specification  of  this  case  study  was  not  carried  out  at  an  high-level  of  abstrac¬ 
tion:  the  modules  to  be  implemented  with  the  hardware  components  (MACHs  and 
FPGAs)  were  specified  using  VIEWlogic  schematics,  while  those  to  be  implemented 
in  software  (transputer)  were  specified  in  C.  To  specify  PLDs,  using  the  ViewPLD 
tool  from  VIEWlogic,  the  JEDEC  format  and,  textual  descriptions  in  ABEL  or 
VHDL  could  also  be  used. 

Although  manually  done,  the  partitioning  process  used  the  performance  of  the  sys¬ 
tem  as  the  main  criterium  for  partition  definition,  but  it  also  used  the  particular 
characteristics  of  each  block.  Using  a  large  granularity  (block  level),  two  candi¬ 
dates  emerged  to  be  implemented  in  hardware:  the  CAM  and  the  VSR.  Since  the 
VSR  operates  in  two  directions  (columns  rotation  and  rows  shift),  one  of  these  op¬ 
erations  would  have  a  low  performance  if  implemented  in  software.  This  leads  to 
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implementing  the  VSR  in  hardware.  As  a  first  approach,  the  CAM  did  not  result 
on  a  hardware  partition,  due  to  its  large  dimensions  (64x68  bits),  but  the  software 
implementation  did  not  significantly  degrade  the  overall  performance  of  the  system. 
Further  hardware  partitions  were  not  created  as  the  PBL  and  the  PEs  are  strongly 
tied  to  the  CAM.  Since  the  CAM  resulted  on  a  software  partition,  these  two  blocks 
are  implemented  in  software  too,  reducing  the  communication  cost  between  two 
partitions. 


Figure  3:  Hardware/software  implementation  of  the  GLiTCH  on  the  EDgAR  plat¬ 
form. 

The  VSR  is  a  bi-dimensional  shift  register  organised  as  a  matrix.  The  GLiTCH  uses 
an  8-bit  video  bus  and  includes  64  PEs,  resulting  on  a  VSR  with  64x8  bits.  The  VSR 
functionality  is  represented  by  the  operations  performed  on  the  data  it  stores.  These 
operations  are  called  SHIFT  and  SWAP,  and  correspond  to  row  shift  and  column 
rotation,  respectively.  The  SHIFT  operation  is  regulated  by  the  frequency  of  an 
external  clock.  This  operation  registers  the  8  bits  of  the  video  input  on  VSR’s  row 
63,  it  shifts  all  rows  one  position  down,  and  row  0  is  sent  to  the  video  output.  The 
SWAP  operation  handles  64-bit  columns,  but  the  present  implementation  of  this 
operation  is  done  in  two  steps,  because  the  data  bus  that  connects  the  LCAs  with 
the  transputer  is  32-bit  wide.  The  SWAP  operation  reads  column  0  to  the  data  bus 
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(parallel  read),  it  registers  the  content  of  data  bus  on  column  7,  and  it  simultaneously 
rotates  all  the  columns  one  position  to  the  right  (parallel  write/column  rotate).  The 
SWAP  operation  is  used  to  implement  some  GLiTCH  instructions:  rotateJmage, 
extract  image  and  all  others  that  use  IMAGE  as  a  parameter. 

The  hardware  components  of  the  GLiTCH  emulator  (VSR)  was  implemented  in 
a  175-pin  LCA.  Two  issues  made  the  VSR  implementation  difficult:  (i)  the  large 
percentage  of  the  available  storage  elements  allocated  to  the  VSR  (8*64=512),  and 
(ii)  the  constraints  imposed  by  the  fixed  position,  on  the  PCB,  of  some  signals  (data, 
address  and  control).  These  two  aspects  result  in  problems:  incomplete  automatic 
routing  of  the  LCA,  long  accumulated  delays  and  fan-out  problems.  Some  of  these 
problems  should  be  reduced,  or  even  eliminated,  if  the  VSR  is  implemented  with  2 
LCAs.  However,  this  option  would  increase  the  cost  associated  with  communication 
between  the  two  VSR  halves,  and  the  chosen  approach  has  the  advantage  of  testing 
the  utilisation  of  the  LCAs  on  the  limits  (more  than  80%  of  logic  used) . 

To  implement  the  software  components  of  the  GLiTCH  emulator  (PEs,  CAM,  PEL 
and  instructions  decoder  blocks),  the  starting  point  was  their  functionality.  The 
functionality  of  these  blocks  was  described  in  ANSI  C,  but  the  emulator  has  some 
minor  aspects  especially  developed  for  transputers  [15].  The  software  components, 
running  on  a  single  transputer,  fully  implement  the  GLiTCH  microinstructions,  ex¬ 
cept  those  microinstructions  using  the  VSR.  If  better  performance  is  required,  the 
parallel  architecture  connected  to  the  platform  should  be  used.  Each  microinstruc¬ 
tion  has  one  sub-operation  executed  by  the  PEL  and  one  sub-operation  executed  by 
the  PEs.  The  PEL  sub-operation  is  executed  before  the  PEs  sub-operation  (except 
in  microinstructions  that  write  to  the  CAM). 

The  interface  between  the  hardware  and  the  software  components  was  implemented 
with  3  types  of  EDgAR  resources:  an  175-pin  LCA,  the  data/address  buses  and  the 
connectors.  The  FPGA  is  used  to  implement  the  VSR  SHIFT  operation,  which  is  not 
synchronised  by  the  same  clock  as  the  other  GLiTCH  components.  The  connectors 
establish  the  communication  between  the  FPGA  used  in  interface  and  the  FPGA 
that  implements  the  hardware  partition. 

The  input  to  the  GLiTCH  emulator  is  the  microcode  of  the  several  microinstructions 
to  execute.  For  better  interface  with  user,  an  assembler  was  developed. 


5  Conclusions  and  future  work 

The  GLiTCH  emulation  led  to  the  conclusion  that  the  performance  of  the  imple¬ 
mented  systems  strongly  depends  on  the  ULP  resources  allocated.  The  performance 
also  depends  on  the  hardware/software  partitioning  procedure.  It  is  not  expected 
that  the  level  of  abstraction  used  to  specify  the  systems  will  significantly  influence 
the  final  performance.  The  case  study  also  demonstrates  that  EDgAR  implements 
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complex  systems  without  scaling  the  platform,  using  connections  to  other  platforms 
or  computing  nodes.  The  platform  architecture  was  simplified  because  the  trans¬ 
puter  requires  a  simple  interface  and  it  supports  the  debugging  of  the  architecture 
where  it  is  included. 

With  the  emulation  of  the  GLiTCH  processor  using  hardware  and  software  com¬ 
ponents,  significant  improvements  were  obtained  on  the  execution  time  of  the  in¬ 
structions  that  use  the  VSR.  Since  the  design  time  was  not  increased  in  the  same 
proportion,  it  is  demonstrated  that  the  platform  can  be  used  successfully  for  hard¬ 
ware  / software  codesign . 

The  case  study  results  in  a  hardware  implementation  without  using  any  MACH, 
because  the  MACHs  are  devoted  to  implement  fast  combinational  logic  blocks,  which 
are  not  present  in  the  VSR.  The  validation  of  the  MACHs  was  verified  through  other 
smaller  sized  systems. 

When  identical  modules  were  implemented  with  both  types  of  FPLDs,  the  delays 
achieved  with  FPGAs  were  bigger  than  the  delays  obtained  with  MACHs.  This 
guarantees  that,  when  both  types  of  FPLDs  are  included  on  the  platform,  better 
performance  is  possible,  since  each  device  type  is  adequate  to  implement  distinct 
parts  of  the  system.  This  idea  is  represented  by  the  two  criteria  used  on  the  hardware 
partitions  generation. 

After  the  promising  results  obtained  with  EDgAR,  the  future  work  will  be  directed 
towards  the  integration  on  a  more  ambitious  platform,  which  will  include  copies  of  an 
updated  version  of  EDgAR,  a  microprogrammable  unit  based  on  a  16-bit  sequencer 
and  the  MIMD  transputer-based  architecture.  The  VHDL  language  will  be  used 
as  the  unified  specification  notation,  to  improve  the  communication  between  the 
different  phases  of  the  codesign  process:  hardware/software  partitioning,  parallel 
co-simulation  and  synthesis. 

While  several  tools  for  automatic  synthesis  are  available,  there  is  much  work  to  be 
done  for  automatic  partitioning  and  co-simulation.  Future  work  includes:  (i)  the 
definition  of  a  more  complete  partitioning  strategy  that  automatically  generates  rep¬ 
resentations  of  the  modules  being  implemented  in  FPLDs,  the  microprogrammable 
unit  or  the  different  transputer  of  the  parallel  architecture,  and  (ii)  the  development 
of  a  co-simulator  that  runs  on  the  parallel  architecture,  whose  main  goal  is  to  speed 
up  the  simulation,  a  generally  time-consuming  process. 
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Abstract  i 

In  this  article,  we  describe  a  Hierarchical  Multi-Views  Modeling  Concepts  for 
Discrete  Event  Systems  Simulation.  We  give  the  basic  concepts  needed  for  the  definition 
of  the  formal  model  allowing  discrete  events  simulation  of  complex  systems[l]. 


Keywords  : 

Object  Oriented  Modeling;  Discrete  Event  Simulation;  abstraction,  time, 
description  hierarchies. 


Introduction  : 

This  paper  deals  with  basic  concepts  for  modeling  and  simulation  of  complex 
systems.  Four  main  features  are  needed  to  reach  this  goal : 

•  definition  of  different  levels  of  abstraction  -  allowing  to  take  into  account  the 

complexity  of  a  system  in  a  gradual  way, 

•  definition  of  different  levels  of  temporal  granularity  [2]  -  allowing  to  take  into 

account  only  the  pertinente  informations  at  a  given  temporal  level, 

•  definition  of  different  views  of  a  system  -  allowing  to  consider  a  system 

according  to  a  structural  or  a  behavioral  view, 

•  definition  of  a  generic  simulation  approach  allowing  to  : 

•  process  the  simulation  of  systems  whatever  the  consideral  view,  level  of 
abstraction  or  level  of  granularity, 

•  simule  different  kinds  of  systems. 

In  order  to  define  such  an  environment,  we  propose  an  original  approach  based  on 
the  simulation  concepts  introduced  by  B.P.  ZEIGLER  [3,4,5,6,7,8,9]  and  the  modeling 
aspects  developed  in  [10,1 1].  This  approach  has  been  used  in  order  to  study  the  behavior 
of  complex  systems  such  as  a  cachment  basin  [12].  We  are  currently  applying  the 
concepts  introduced  in  this  article  for  the  design  of  embedded  systems  involving 
hardware  and  software  components. 

In  the  first  section,  basic  modeling  concepts  are  presented.  The  second  section  is 
devoted  to  the  description  of  the  hierarchical  multi-views  modeling  scheme.  In  the  last 
part,  we  briefly  present  an  object  oriented  simulation  architecture. 


*  this  work  is  supported  by  the  EEC  :  HCM  BELSIGN  Network  Contract  n°  CHRX-CT  94-0459 


1-Basic  Modeling  notions  : 

The  modeling  relation  (see  Fig.  1)  allows  to  give  simplified  representation  of 
system  ;  the  model  is  thus  an  image  of  the  system.  The  model  allows  to  study  and 
anticipate  the  reactions  of  the  system. 


Model 


Fig.  1  :  Modelisation  relation 


Four  main  concepts  are  used  in  our  approach  : 

•  multi-view  notion  -  a  system  is  represented  by  a  set  of  distinct  views 
corresponding  to  its  differents  aspects, 

•  abstraction  hierarchy  -  a  system  can  be  described  using  different  levels  of  details 
called  abstraction  levels, 

•  time  hierarchy  -  a  system  can  be  considered  under  several  temporal  detail  levels 
called  "granularity  levels", 

•  description  hierarchy  -  a  system  can  be  described  by  a  set  of  sub-systems  at 
different  description  levels  but  at  the  same  abstraction. 

In  order  to  take  into  account  the  different  aspects  of  a  model  (  structural,  behavioral, 
time...),  we  propose  two  representations : 

•  the  global  representation  :  composed  by  all  the  desciptions  of  the  model  (the 
different  views  and  the  different  levels  of  hierarchy).  This  hierarchical  approach  is 
made  by  different  levels  : 

-  the  abstraction  levels 

-  the  time  levels 

-  the  description  levels 

•  the  modeling  space  :  is  another  expressive  representation  which  consists  in 
pointing  out  three  dimentions  : 

-  the  views 

-  the  abstraction  levels 

-  the  time  levels 

All  the  points  of  this  space  represent  the  model  for  : 

-  a  given  view 

-  a  given  abstraction  level 

-  a  given  time  level 


2-Modeling  : 

This  section  deals  with  our  modeling  approach.  Sub-section  2.1  give  the  informal 
modeling  scheme.  Sub-section  2.2  give  the  formal  definition  of  the  basic  features  of  our 
approach. 


2.1-Informal  Model  : 

We  present  how  the  system  is  represented  in  the  three-dimension  space 
(abstraction  levels,  time  levels,  views) [12].  We'll  describe  a  set  of  functions  which 
allows  the  translation  between  the  different  representations  of  the  model. 
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2.1.1-The  Structural  View  : 

The  Structural  View  is  composed  by  different  abstraction  levels  which  can  be 
described  under  different  time  levels.  A  Structural  View  represents  a  potential  structure 
of  the  system.  It's  an  interconnexion  of  nodes.  The  nodes  receive  and  send  information 
by  means  of  its  input  and  output  ports. 


2.1.2-The  Behavioral  View  : 

The  Behavioral  view  doesn't  represent  a  structure  of  the  system  but  only  its 
behavior.  We  have  different  levels  of  description.  The  behavior  is  expressed  by  means 
of  a  graph  structure.  In  order  to  represent  the  behavior  of  one  component,  we  use  the 
"desc"  function  which  provides  the  set  of  components  which  will  allows  to  describe  the 
behavior  (description  hierarchy).  It  is  important  to  point  out  that  a  Structural  View  and  a 
Behavioral  View  expressed  by  graph  structure  involve  different  concepts.  The 
specification  of  the  interconnexion  of  basic  components  represents  the  definition  of  a 
Coupled  Model  and  the  specification  of  a  basic  component  represents  the  definition  of 
an  Atomic  Model.  A  Coupled  Model  can  be  used  like  a  basic  component  in  a  larger 
coupled  model.  Atomic  and  Coupled  models  have  been  defined  in  [6].  We  present  in  the 
following  a  brief  description  of  these  models  : 

•  A  Coupled  Model  contains  the  following  information  : 

-  the  inputs 

-  the  outputs 

-  the  names  of  the  model  components 

-  the  external  input  coupling 

-  the  external  output  coupling 

-  the  internal  coupling 

-  the  priority  list 

•  An  Atomic  Model  provides  a  local  description  of  a  system's  dynamic  : 

M  =  <  X,  S,  Y,  Sint,  5ext,  I,  ta  > 

X  :  set  of  external  input  events 
S  ;  set  of  sequential  states 
Y  :  set  of  external  output  events 

5int  :  internal  transition  function 

5ext  :  external  transition  function 

1  :  output  function 

ta  :  time  advance  function 


2.1.3-Translation  functions  : 

A  set  of  functions  have  been  defined  in  order  to  allow  the  translation  of 
information  between  different  levels  and  views  : 

•  the  trans  function  allows  to  transmit  informations  between  two 
abstraction  levels. 

•  the  comp  function  can  be  used  for  two  kinds  of  operations  : 

-  to  decompose  a  model  at  a  given  abstraction  level  into  a  set  of  sub¬ 
models  at  another  abstraction  level. 

•  the  conv  function  allows  the  transfer  of  information  between  the  time 
levels. 

•  the  desc  function  provides  the  set  of  components  which  compose  a  given 
model. 
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2.2-Formal  Modeling  Scheme  : 

We  give  in  this  sub-section  a  formal  expression  of  the  basic  features  of  our 
modeling  scheme.  Let  us  call  Mq  the  general  model  of  a  given  system.  Mq  is  composed 
by  the  set  of  models  M  describing  the  system  according  to  behavioral  and  structural  views 
(Me  and  Ms). 

Chv  and  Synth  are  two  classes  of  functions  allowing  the  translation  of  information 
between  different  views. 

Mq={  M,Niv^,Nivg, Chv, Synth  } 

M  =  MgKJ 

with  Mg  =  behavioral  model 
and  =  structural  model 
=  Set  of  abstraction  level 
Nivg  =  Set  of  granularity  level 
Chv  =  map  ( Niv^ ,  Ws )  ^  ( Niv^ ,  Nivg ,  ,  A^c ) 

{niv‘^,niVg,n‘J  {niv'^,niv'^ ,niv\}n'J 
Synth  =  map  {Niv ^,Nivg,Niv g„P{N g))  {Niv ^,NiVg,P{N ^y) 

{niv'^,nivg  ,nivl,‘^eV^)  {niv[,niVg  ,eT^) 
with  el  e  P{Ng) 
and  e2  eP{Ns) 

P{Ng) :  set  of  the  parts  of  Ng 
P{Ns)  :  set  of  the  parts  of 


2.2.1-Formal  Structural  Model  : 

We  give  in  this  part  a  formal  expression  of  the  structural  modeling  scheme. 

M^={  Ng,C^,P^,Tj,\^,(p,%,Y,TranSp,Compj^,ConVp  } 

Ng  =  Set  of  the  nodes  of  the  structural  model 

Cg  =  Set  of  the  node  connexions  of  the  structural  model 

Pg  =  Set  of  the  ports  of  the  structural  model  (Pg  =  Pg^  u  Pg ) 

Tg^  =  Set  of  the  port  types  of  the  structural  model 
i/r  =  map  Pg  — >  Ng 
p\-^n 

(p  =  map  Ng  — »  P{Pg) 
n\-^  p 
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X  =  map  C5  ^  ,PiPs^ )) 

C  (P|,P2) 

7  =  map  Ps  ->  7/ 
p\-^  t 

with  p  eP^  =  Pg  Ps 
t  G  [in,out} 

if  Y(t)  =  in  then  p  e  P/ 


Transp  =  map  (Niv^,NivG,P(Ps))  ^  (Mv^,Mvc,P(P5)) 
(niv' ,  ,  p; J  ^  (niv^a  > ’  Pm  ^ 


Compj^  =  map  (Niv^,NivQ,N^)  (Niv^,NivQ,PiNs)) 
{niv[,niVg,n‘J  (mv' ,mv^,4) 
with  G  P(A^s) 


Convp  =  map  {Niv^,NiV(j,P{Ps))  iNiv^,NivQ,P(Ps)) 
(niv[ ,  niVg  ,p‘J^  (niv‘^ ,  n/v" ,  p;, ) 


2.2.2-Formal  Behavioral  Model  : 

In  this  part  we  give  a  formal  description  of  the  behavioral  modeling  scheme.  This 
description  involves  the  definition  of  two  sets  of  attributes  :  AMC  and  AMA  (respectively 
the  set  of  attributes  of  a  Coupled  Model  and  AMA  the  set  of  attributes  of  an  Atomic 
Model). 

Mc  =  {  Nc,Pc,AMC,AMA,NivD,TranSp,Convp,DescMc^DescMA  } 

-  Set  of  the  nodes  of  the  behavioral  model 
P^  =  Set  of  the  ports  of  the  structural  model 
AMC  =  {  1,0,  C,  COE,  CIE,  Cl,  LP  } 

I  =  Set  of  the  input  ports  of  the  coupled  models  and  I  a  P{Pc) 

O  =  Set  of  the  output  ports  of  the  coupled  models  and  O  e  P(Pc) 

C  =  Set  of  the  componants  of  the  coupled  models  and  C<^P{Nc) 

COE  =  Set  of  the  externe  output  couplings  of  the  coupled  models 
CIE  =  Set  of  the  external  input  couplings  of  the  coupled  models 
Cl  =  Set  of  the  internal  couplings  of  the  coupled  models 
LP  -  Set  of  the  priority  lists  of  the  coupled  models 
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AMA  =  {  XJ,S,^ext,^mX,K,TA  } 

X  =  Set  of  the  input  ports  of  the  atomic  models 
Y  =  Set  of  the  output  ports  of  the  atomic  models 
S  -  Set  of  the  states  of  the  atomic  models 

Aext  =  Set  of  the  external  transition  functions  of  the  atomic  models 
Aint  =  Set  of  the  internal  transition  functions  of  the  atomic  models 
A  =  Set  of  the  output  functions  of  the  atomic  models 
TA  =  Set  of  the  time  -  advanced  functions  of  the  atomic  models 

NiV[)  =  Set  of  the  description  levels  of  the  behavioral  model 

TranSp  =  map  (Niv^,NiV(j,NiV[),P{P(^))  {Niv^,NiV(j,Nivp„P(Pc)) 
(niv‘^,niv^,nivyp'J  ^ 

Convp  =  map  (X/v^,Mvg,Mv£„P(Pc)) 


Desc,^(;-= map  (NivA,NivQ,Nivp),MC)  {NivA,NivQ,NiVp„AMC) 


{niv‘^ ,  , niv%‘'mc‘^ ) 


{niVa  t  ^m’mc ^m'mc  ^m'mc 


:ipin) 


Desc^A  = 


map  {NivA,NivQ,Nivp),MA)  (NivA,NivQ,Nivp),AMA) 

”1  q^J  \  ,  V 


{niv‘^,niv^ ,nivyma‘^) 


(niv‘^,niv^  ,niv^ 


q  qy‘  ‘iy‘  9c'  95int'  ^1'  ^ta'  ) 


3-Current  and  Future  Work  : 

Our  current  work  concerns  the  different  aspects  of  the  simulation  and  the 
implementation.  Indeed,  the  simulation  is  divided  in  two  parts  : 

•  the  structural  part 

•  the  behavioral  part 

We  present  the  implementation  of  the  simulation,  and  how  the  Object  Oriented 
Programing's  concepts  [14,15]are  used  in  order  to  obtain  an  evolutive,  modulare  and 
hierarchical  simulator.  The  architecture  of  the  behavioral  part  of  our  environment  is 
represented  in  Fig.  2  : 
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MODELING  SIMULATION 

Fip.  2  :  Architecture  of  the  behavioral  part 

We  are  currently  developing  the  specifications  of  the  general  environment,  with 
emphasis  on  the  structural  part  of  the  simulation  and  the  integration  of  the  already 
implemented  part.  This  environment  will  be  used  for  the  design  and  the  validation  of  an 
embedded  system  in  the  framework  of  an  international  project  [16],  This  system  will  be  a 
test  bed  for  conducting  trade-off  studies  between  technologies,  fault  tolerence  and  testing 
in  space.  The  designed  system  should  be  able  to  provide  data  which  characterize  patterns 
of  test  defects  occurring  in  space. 
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Abstract 

We  present  a  formal  system  interpreted  in  a  fimctional  algebra.  Well-formed  expres¬ 
sions  depict  circuit  arcliitectures  and  their  interpretations  correspond  to  the  associated 
behaviours.  We  also  describe  our  approach  for  interfacing  it  with  proof  assistants  (Coq 
and  LP)  in  view  of  formal  verification  and  synthesis.  Then,  we  briefly  comment  our  expe¬ 
riences  in  the  field  of  formal  proof. 

Keywords  :  Formal  verification,  formal  system,  theorem  provers 


Introduction 

VLSI  chips  reliability  is  a  critical  question  within  the  more  general  framework  of  the  production 
of  automated  systems.  Moreover,  the  manufacturing  process  cost  makes  it  essential  to  detect 
design  errors  before  the  physical  realization.  Correctness  verification  is  usually  done  by  simula¬ 
tion.  However  exhaustive  simulations  required  for  zero  defect  design  are  untractable  in  case  of 
large  devices.  Thus,  the  present  trends  are  to  use  formal  methods  for  mathematical  validation 
of  circuits. 

Formal  verification  of  digital  circuits  requires  to  abstract  devices  into  mathematical  objects, 
to  carry  out  algebraic  transformations  on  them,  and  finally  to  prove  properties.  The  work 
presented  in  this  paper  is  part  of  a  more  general  study  concerning  a  CAD  verification  oriented 
system  for  synchronous  circuits  (Formath:  FoRmal  Modelling  And  THeorem  provers),  which 
satisfies  these  requirements. 

Roughly  speaking,  it  is  composed  of  three  parts; 

•  a  formal  system,  called  the  P-calculus,  which  is  the  core  of  Formath. 

•  theorem  provers,  presently  Coq  and  the  Larch  Prover  (lp),  and  the  interface  between  the 
formal  system  and  the  provers. 

•  user  interfaces,  for  inputting  specifications  and  descriptions  of  circuits;  either  by  directly 
entering  P-calculus  expressions,  or  by  translating  current  hdl  (such  as  vhdl)  descriptions 
into  P-calculus. 

Our  purpose  in  this  article  is  to  develop  the  two  first  points  above.  The  P-calculus  is  not  a 
simple  stream  based  functional  hdl,  but  it  is  an  actual  formal  system  which  allows  algebraic 
transformations.  Stream  based  functional  modelling  of  hardware  has  been  widely  used  and 
many  functional  HDL  haven  been  already  defined  such  as  lcf-lsm  [12],  lustre[14],  muFP  [22], 
HML  [18]  •  •  •  (see  also  [15,  17]  •  ■  •).  These  languages  allow  to  describe  and  to  simulate  circuits, 
and  sometimes  to  synthesize  FSM,  but  they  do  not  permit  to  directly  process  automated  formal 
transformations. 

In  [19]  a  functional  algebra  was  introduced  which  was  named  P-Calculus  for  the  first  time 
by  Bronstein  in  [6].  We  modify  this  initial  algebra  and  enrich  it  with  new  operators.  In  addition 
we  couple  it  with  a  formal  system  involving  a  typed  formal  language  and  a  rewriting  system 
which  has  been  proven  to  be  complete  [2,  3].  The  resulting  new  P-Calculus  thus  establishes  a 
clear  distinction  between  structures  (described  in  a  modular  and  hierarchical  way  by  expressions 
of  the  formal  system)  and  behaviours  (functions  of  the  algebra),  both  being  linked  by  means 
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of  an  interpretation  function.  Moreover,  the  rewrite  rules  correspond  to  semantics  preserving 
transformations  that  are  mechanically  performed  independently  of  the  theorem  prover  to  be 
used.  Among  other  advantages,  these  preliminary  transformations  permit  to  detect  early  some 
kinds  of  errors  and  to  simplify  the  proof  process  to  come.  Moreover,  due  to  the  readibility  of 
the  syntax,  expressing  specifications,  transformations  and  refinements  is  straightforward. 

The  complexity  of  the  mathematical  demonstrations  and  of  circuits  makes  it  crucial  to 
have  proof  processes  validated  by  proof-assistants.  Several  demonstration  tools  are  already 
well  known  and  used  in  the  community  of  the  formal  hardware  verification.  We  can  cite,  for 
example:  Nqthm  [5],  HOL  [13],  Nuprl  [7],  ...  At  present,  we  experiment  with  two  provers  LP 
[10]  and  Coq  [9],  which  have  very  different  features  and  thus  are  complementary  in  resolving 
the  problems  raised  by  such  or  such  devices.  An  interface  is  devoted  to  the  translation  of 
the  P-calculus  expressions  into  the  provers  syntax.  This  interface  also  allows  to  carry  out 
proof  pre-processing  independently  of  the  provers.  After  doing  some  transformations  such  as 
normalizations,  after  detecting  errors  and  possibly  reducing  the  complexity  of  the  problem  to 
be  resolved,  the  interface  provides  uniform  expressions  that  are  translated  in  a  precise  prover 
syntax. 

The  first  section  presents  the  main  features  of  the  P-calculus  :  the  formal  system  with  its 
language,  its  interpretation  in  the  functional  algebra,  and  a  decomposition  result  obtained  by 
rewrite-rules.  Then  we  give  in  a  second  part  a  brief  description  of  Coq  and  LP  as  well  as  the 
essential  aspects  of  the  interface  between  the  P-calculus  and  these  provers.  This  section  ends 
by  a  short  discussion  about  the  experience  we  got  from  various  examples  that  we  have  handled. 
More  details  about  the  proofs  can  be  found  in  [2,  1,  8]. 


1  The  P— calculus 

1.1  The  functional  algebra 

Let  us  start  by  giving  some  basic  definitions.  We  first  introduce  the  notion  of  temporal  se¬ 
quences  that  models  signals  and  of  sequential  functions  that  are  functions  on  these  secpiences. 
We  shall  deal  only  with  sequential  circuits  synchronized  by  one  clock  whose  cycles  are  formally 
represented  by  the  naturals.  Thus  a  signal  x  in  a  circuit  will  be  a  sequence  so  called 

a  temporal  sequence,  whose  set  of  values  is  a  basic  type  (such  as,  in  practice,  booleans,  natu¬ 
rals  ■  •  •).  The  sequence  x  =  (x(t))tg^v  represents  the  history  of  the  wire  x.  In  the  following, 
the  word  sequence  will  mean  temporal  sequence  and  Sp  will  denote  the  set  of  all  the  temporal 
sequences  of  type  T. 

The  behaviour  of  a  circuit  can  be  modelled  by  a  function,  called  a  sequential  function,  which 
associates  a  sequence  vector  (the  output  vector)  with  a  sequence  vector  (the  input  vector). 

Example: 

i,  j,  X,  y  are  boolean  sequences.  The  be¬ 
haviour  of  this  half-adder  is  a  sequential  func¬ 
tion: 

h^add  :  Sjb  x  Sjb  —t  Sjb  x  Sjb 

{i,j)  h^add{i,  j)  =  (x,  y) 

X  y 

The  basic  combinational  components  (without  temporal  dependency)  are  concrete  realiza¬ 
tions  of  arithmetical  and  boolean  functions.  From  these  functions,  defined  on  the  basic  ty'pes, 
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sequential  functions  can  be  defined  on  the  sequences.  For  example,  and  induces  the  sequential 
function  and  :  Sjb  x  Sb  Sjb  defined  by 

and(i,j)  =  {and{i{t),j{t)))t^iN 

Thus,  the  function  li.add,  which  models  the  behaviour  of  a  half-adder  can  be  expressed  in 
different  ways.  Starting  from  the  expression  of  h-add  on  the  input  (i,  j)  at  time  t: 

h.add{i,j){t)  =  {xor{i{t)J{t)),and{i{t),j{t))) 

its  abstraction  is:  h.add[i,j)  —  {xor[i, i),and{i,  j))  that  we  write,  in  a  more  concise  way 

liMdd  —  [lor,  and]  =  [xor,  and] 

A  sequential  function  F,  which  is  obtained  in  such  a  way  from  a  function  /  (one  writes  F  —  J) 
is  called  a  projective  function.  Note  that  not  all  the  sequential  functions  are  projective.  More 
precisely  the  following  result  is  proved  in  [2]. 

Proposition  1.1  A  sequential  function  F  is  projective  if  and  only  if,  for  all  sequence  vectors 
X  and  Y 

Vt,t'  €iV  X{t)  =Y{t')=^  F[X){t)  =  F{Y){t') 


D  =  BoA 


D 


D  =  [B,  A] 


D 


02  01 


Figure  1:  Composition  and  construction 

The  composition  of  sequential  functions  expresses  the  connection  in  series  of  two  modules 
(fig.  1  on  the  left)  and  the  construction  represents  the  composition  in  parallel  of  two  modules 
with  the  same  inputs  (fig.  1  on  the  right).  Finally,  the  selection  operators  Sef  [i  £  IN*)  denote 
the  i*^^  projections. 


Example: 

BA  Ri 


The  behaviour  of  the  adder  on  the  left  can  be  expressed  by  the 
equation: 

ADD{Ri,  A,  B)  =  {Seli{h.add[Ri,  Sel\{h^add[A,  B))), 

or{Sel2{h^add{Ri,  Seli{h-add{A,  B)))), 
Selilh.add{A,  B))) 

or,  in  a  pure  functional  way  without  variables  (close  to  that  in 

[4]): 

ADD  =  [5e/i  o  li_addo  [Sell,  Sell  o  h.addo  [5e/].,  Se/s]], 

or  o  [5e/2  o  h.add  o  [Sell ,  Sell  o  liMdd  o  [5e/i ,  55/3]], 
Sell ,  Sell  °  h^add  o  [Sell ,  55/3]]] 


Figure  2:  An  adder 

It  is  easy  to  prove  that  the  class  of  the  projective  sequential  functions  is  stable  for  the 
composition  and  the  construction,  and  that  it  contains  all  selectors. 
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When  extending  our  purpose  to  the  sequential  circuits,  it  becomes  necessary  to  take  into 
account  temporal  constraints,  and  to  include  a  new  operator:  the  past  operator V .  This  operator 
is  defined  on  every  sequence  x  by: 

Vt  6  W  Vix){t  +  l)  =  x{t). 


and  in  fact,  it  models  a  register: 


X 

I _ 

REG 

- 

Px 

The  definition  of  V  is  extended  to  sequence  vectors  by: 


Note  that  V{x)  has  an  undefined  value  for  <  =  0.  This  corresponds  to  the  fact  that  the 
initial  value  of  a  register  is  not  part  of  the  circuit  architecture. 

The  past  operator  V  is  obviously  not  projective.  A  useful  property  of  the  past  operator  'P 
is  that  it  commutes  with  any  projective  sequential  function.  That  formally  expresses  classical 
retiming. 

Example: 

The  output  O  is  defined  by 
O  =  V{mux[c, 

XI, 

V(rnux[c, 

X2, 

P(mux(c,X3,SI)))))) 
where  mux[x,y,z)  =  if  x  then  y  else  z 
Figure  3:  A  serial  shift  register  with  parallel  inputs 


X3  X2  XI 


1.2  The  formal  system 

We  define  a  typed  language  in  which  the  well-formed  formulae  will  describe  circuit  architecture. 
Then  each  expression  is  interpreted  by  a  function  that  represents  the  semantics  (the  behaviour) 
of  the  circuit. 

We  first  introduce  the  simple  P-calculus,  in  which  circuits  without  loop  will  be  described. 
Then  we  enrich  it  with  a  recursion  operator  for  handling  general  devices. 

1.2.1  Simple  P-calculus 
Syntax 

The  set  of  object  types  is  defined  as  the  least  set  which  contains  types  of  sequences  on  basic 
types  and  which  is  closed  for  the  cartesian  product. 

In  addition,  from  any  two  object  types  Ti  and  T2  and  by  means  of  the  constructor  liew 
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types  Tj  — >  T2  can  be  defined.  They  are  called  functional  types. 


Vocabulary 

•  With  each  functional  type  T  we  associate: 

—  a  set  Vt  of  functional  variables  of  type  T  (which  will  be  interpreted  as  projective 
sequential  functions) 

—  a  set  Ct  of  functional  constants  of  type  T  (interpreted  as  sequential  function  corre¬ 
sponding  to  constant  functions) 

•  with  each  object  type  To  is  associated  a  family  (P”)n>o  of  type  To  — )■  To  (P"  will  represent 
the  n'^*'  power  of  P) 

•  for  all  m  >  1,  for  all  object  types  Ti,  -  ■  ■  ,Tm  and  for  all  i  G  {1,  ■  ■  ■ ,  m}  an  element  Si  of 
type  Ti  X  ■■■  X  Tm  -t-  Ti  is  given  (in  the  interpretation  it  will  be  the  i^*’  projection). 

The  vocabulary  consists  of  all  the  elements  defined  above  and  of  four  additional  symbols  0 
(later  interpreted  as  the  functional  composition),  (coma),  “[”  and  “]”  (which  will  be  used 
for  representing  the  construction  operator). 

Expressions 

The  expressions  of  the  simple  P-calculus  (P-expressions)  are  defined  cis  follows. 

Let  T,  T',r"  be  three  object  types: 

•  for  all  c  S  Ct^T'  ,  c  is  an  P-expression  of  type  T  T' 

•  for  all  m  >  1,  for  all  object  types  Tj ,  -  ■  • ,  Tm  and  for  all  f  6  {1,  •  ■  ■ ,  m}.  Si  is  a  P-expression 
of  type  Ti  X  ■  ■  ■  x,Tm  Ti 

•  if  e  is  a  P-expression  of  type  T  — >■  T',  if  P"  is  of  type  T'  — >■  T'  and  if  /  S  then 

P”  O  e  is  a  P-expression  of  type  T  T'  and  /  Q  e  is  a  P-expression  of  type  T  T" 

•  If  ei  and  eo  are  P-expressions  of  type  T  T'  and  T'  — >  T"  respectively,  then  62  O  ei  is 
a  P-expression  of  type  T  — >  T" 

•  Let  Ti,  -  ■  ■  ,Tn  be  object  types,  if  ei ,  •  •  ■ ,  e„  are  P-expressions  of  type  T  — >■  Pi ,  •  •  ■ ,  T  — >  r„ 
respectively,  then  [ei,  •  ■  • ,  £„]  is  a  P-expression  of  type  T  — >  Ti  x  •  •  ■  x  T„ 

Nothing  else  is  a  P-expression. 

Example: 

Let  us  consider  the  shift  register  with  parallel  loading  described  in  figure  3.  Let  us  take 
(XI,  ^2,  iV3, 5/,  c)  as  input  vector  and  let  MUX  be  a  functional  variable  of  type  Sjb  x  Sib  x 
Sb  — t  Sb-  The  structure  of  the  circuit  is  modelled  by  the  following  P-expression: 


^shijt^eg  —  0  MUX  0  [.5*5, 

51, 

P^QMUXQ[S,, 

S2, 

p^eMUXQ[Sro, 

S3, 

54]]] 
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Interpretation 


The  interpretation  of  the  P-expressions  depends  on  an  arbitrary  interpretation  of  the  func¬ 
tional  variables  and  of  the  functional  constants.  Let  I  be  an  application  which: 

•  with  each  functional  variable  /  G  associates  a  projective  sequential  function 

/(/)  :  T-^r 

•  with  each  functional  constant  c  G  Ct-^T'  associates  the  sequential  function  corresponding 
to  a  constant  function  1(c)  :  T  — )■  T'. 

This  application  I  extends  to  all  the  P-expressions  in  the  following  way. 

Let  e,ei,  ■  ■  ■ ,  £„  be  P-expressions,  let  /  be  a  functional  variable: 

.  /(5.)  =  Sdi, 

.  /(P"0e)='P"o/(e), 

.  /(/0e)  =/(/)o/(e), 

•  /([ei  ■  •  -Cn])  =  [/(ei),  ■  •  • ,  I{en)] 

•  /{fii  O  Co)  =  /(ci)  o  f(e2) 

It  is  easily  verified  that  the  types  of  the  expressions  insure  the  consistency  of  the  compositions 
and  the  constructions. 

Example: 

On  the  device  in  figure  3,  the  output  O  is  described  by  the  equation: 

O  =  V(mux{c,  Xl,'P(mux{c,  X2,V(mux(c,  JYS,  SI)))))) 

=  I{e,hiJt.reg){Xl,X2,X3,SI,c) 

In  fact,  the  interpretation  I  defines  the  semantics  of  the  P-expressions  and  thus  the  func¬ 
tional  behaviour  of  the  circuits.  Therefore  two  expressions  can  be  said  to  be  equivalent  when 
the  associated  circuits  have  the  same  behaviour,  that  is  when  the  expressions  have  the  same 
interpretation. 

Characterizing  temporal  and  combinational  parts 

Let  us  present  this  notion  on  the  example  of  the  shift  register  in  figure  3.  As  V  commutes 
with  any  projective  sequential  function  we  transform  the  equation  defining  the  output  O  in  the 
following  way: 

0  =  V{mux(c,Xl,P{rnu^(c,X2,WnIx{V(c),T{X3),ViSI)))))) 

=  V(mux(c,  Al,  Tnux(V (c) ,V {X2) ,  mux{J^'^[c),V~{X3),V'^{SI))))) 

=  rnu^.(V(c),V(Xl),rmnE{V^(c),V^{X2),rnux(V'^{c),V'\X3),V^(SI)))) 

The  last  expression  corresponds  to  the  normal  form  of  the  expression  of  O. 

Let  us  set: 


P(A1)  =  ;  P-(X2)  =  V2  ;  P^{X3)  =  A3  ;  P^{SI)  =  V4 

P{c)  =  A5  ;  P2(c)  =  A6  ;  P^{c)  =  A7 
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The  equation  becomes: 


O  =  mux{V5,  VI,  mux(VQ,  V2,  mux[V7 ,  K3,  V4))) 

This  last  expression  of  O  represents  the  combinational  part  of  the  circuit.  On  the  other  hand, 
all  the  temporal  features  are  expressed  by  the  equalities  1. 

Such  a  decomposition  can  be  viewed  as  the  construction  of  the  equivalent  circuit  in  figure  4. 


SI  X3  X2  XI 


Figure  4:  Shift  register  -  Temporal  and  combinational  parts 

Formally,  this  decomposition  method  corresponds  to  a  rewrite  system  on  the  P-expressions 
the  completeness  of  which  has  been  proven  in  [2].  This  rewrite  system  automatically  generates 
the  normal  form  of  an  expression.  This  is  of  interest,  among  other  things,  for  syntactically 
characterizing  certain  classes  of  circuits  and  for  simplifying  proof  processes. 

This  transformation  must  not  be  confused  with  the  classical  decomposition  method  illus¬ 
trated  by  the  figure  5. 


Figure  5:  Shift  register  -  Classical  decomposition 


1.2.2  Recursive  P-calciilus 


In  order  to  take  into  account  structural  loops,  a  recursion  operator  must  be  added  to  the 
P-calculus.  Indeed,  behaviours  of  circuits  with  loops  cannot  be  defined  algebraically.  They  are 
sequential  functions  obtained  as  the  least  fixed  point,  if  any,  of  an  equation.  Our  approach, 
close  to  [16]  is  explained  in  details  in  [2]. 
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A. 


Figure  6: 

In  such  a  way,  we  can  model  a  module  all  outputs  of  which  are  connected  to  inputs  (see  fig¬ 
ure  6). 

It  can  be  shown  that  all  other  forms  of  recursions  in  circuit  structures  boil  down  to  this 
particular  case.  Thus  we  only  consider  circuits  D  depicted  in  figure  6.  Let  n  and  m  be  the 
sizesnb  of  the  vectors  I  and  J .  The  informal  idea  is  to  describe  the  behaviour  of  the  circuit  D 
by  a  seciuential  function,  still  called  D  such  that; 

These  considerations  justify  the  following  definition. 


Definition.  Let  A  :  5"+'"  —>■  S"'  be  a  sequential  function.  We  define  the  sequential  function 
REC{A)  :  — )■  as  the  least  solution  (the  less  defined  solution),  if  any,  of  the  equation: 

REC{A)  =  A  o[l\s.,  REC{A)] 


We  have  proved  that  in  case  of  well  synchronized  circuits  in  which  every  loop  contains  at 
least  one  register,  and  for  each  set  of  registers  initial  values,  the  equation  has  one  and  only  one 
solution. 

Thus,  we  are  led  to  introduce  an  additional  symbol  R,  in  the  simple  P-calculus,  which  will 
be  interpreted  by  the  recursive  operator  REC. 

Expressions  of  the  recursive  P-calcnlus 

The  expressions  of  the  recursive  P-calculus  are  defined  as  follows. 

•  Every  expression  of  the  simple  P-calculus  is  an  expression  of  the  recursive  P-calculus  and 
its  type  is  unchanged. 

•  Let  e  be  an  expression  of  the  simple  P-calculus  of  type  Ti  x  To  — >•  T2.  Then  i?(e)  is  an 
expression  of  the  recursive  P-calculus  of  type  Ti  — >■  To 

Finally,  it  remains  to  extend  the  definition  of  the  interpretation  I  to  these  new  expressions. 
Interpretation 

Let  e,ei,  •  ■  €„  be  expressions  of  recursive  P-calculus,  let  /  be  a  functional  variable  then: 

.  I(Si)  =  Seli, 

•  /(P"  Oe)  =P"  o/(e), 

.  /(/Oe)  =  /(/)oJ(e), 

•  /([ei  ■  ■■Cn])  =  [/(ei),-’,  /(e„)] 

•  /(ei  0  eo)  =  I{ei)  o  I{eo) 

Let  e  be  an  expression  of  the  simple  P-calculus. 

.  /(P(e))  =  REC{J{e)) 
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NS  road 


Figure  7:  Road  intersection  with  a  traffic  light  and  its  implementation 


Example; 

Let  us  consider  the  traffic  light  controller  (figure  7)  proposed  in  [23].  The  device  detects 
means  of  sensors  (CarOnNS,CarOnEW)  the  presence  of  cars  waiting  on  a  North-South  road 
(NS)  and  on  an  East-West  road  (EW).  According  to  the  french  protocol  and  depending  on  the 
color  of  the  lights,  it  makes  the  expected  changes. 

This  circuit  is  described  by  the  following  P-expression  where  the  inputs  are  two  boolean 
signals  (representing  the  sensors)  and  the  outputs  are  the  light  colors. 

TRLIGHT  = 

R{[P  O  MUX  ©  [^C  0  [S3 ,  orange], 
red, 

MUX  0  [EQC  ©  [S4,  orange], 
green, 

MUX  O  [AND  0  [Si ,  EQC  ©  [S3,  green]],  orange,  S3]]], 

P  0  MU X  O  [EQC  0  [S4 ,  orange], 
red, 

MUX  O  [EQC  ©  [S3,  orange], 
green, 

MUX  0  [AND  ©  [EQC  ©  [S4,  green],  S2],  orange,  S4]]]]) 


2  Use  of  Theorem  provers 

2.1  Formath  interface  between  the  P-calculus  and  the  provers 

A  P-calculus  architectural  description  of  a  circuit  consists  of  two  parts: 

•  a  P-calculus  expression  which  describes  the  structure  of  the  circuit, 

•  an  interpretation  of  the  functional  variables  occurring  in  the  expression. 

This  amounts  to  consider  the  functional  variables  eis  black  boxes  only  described  by  their  be¬ 
haviour.  The  user  is  given  a  lexicon  of  functional  variable  identifiers  with  predefined  semantics. 
In  each  prover  these  identifiers  will  be  the  name  of  functions  implementing  the  interpretation 
of  the  variables. 

Moreover,  starting  from  a  P-calculus  description,  if  the  expression  is  of  the  form  /?.(.4), 
Formath  interface  first  generates  the  normal  form  (according  to  the  transformations  of  the 
formal  system)  of  the  expression  A.  On  the  example  of  the  traffic  light  controller,  it  results  in: 
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TRLIGHT  = 

R([MUX  O  [^C  0  [P  ©  53,  orcmy^], 

red, 

MUX  0  [EQC  0  [P  ©  54,  orange], 
green, 

MUX  0  [AND  O  [P  0  5i ,  EQC  ©  [P  O  Ps ,  W^]l 
orange, 

PQSz]]], 

MUX  0  [EQC  ©  [P  ©  54,  orange], 
red, 

MU X  ©  [EQC  ©  [P  ©  53 ,  orange], 
green, 

MUX  0  [AND  0  [EQC  0  [P  ©  Si, green],  P  ©  52], 
orange, 

POSi]]]]) 

Then  the  following  points  are  automatically  performed: 

•  A  precedence  graph  is  built.  It  describes  the  dependencies  between  signal  values  in  the 
circuit  at  the  same  step  of  time. 

•  By  means  of  a  topological  sort  of  this  graph,  the  fact  that  each  structural  loop  in  the 
circuit  includes  at  least  one  register  is  checked. 

•  In  this  case,  recursive  equations  describing  the  outputs,  are  generated.  Providing  that 
initial  values  are  given,  these  equations  will  be  translated  into  recursive  definitions  in  the 
syntax  of  the  suitable  prover. 

Example: 

Let  us  consider  the  informal  example  of  a  circuit  whith  input  I  —  [li,  I2]  and  output  O  — 
[01,02,03],  described  by  means  of  the  recursive  equation 

0  =  F(/,0) 

where  F  =  [Fi,  F2,  Ps]- 

Assume  that  this  equation  is  normalized  (according  to  the  transformations)  in  a  system  of  the 
form: 

Oi  =  P((P(0i),p2(0i),P(02),03) 

O2  =  K(0i,P(02),P(03),P''(03))  (2) 

O3  =  F^iP^iOs)) 

where  no  P  occurs  in  P,'. 

By  introducing  the  time  variable  t,  the  following  system  is  automatically  produced: 

Oi(t  +  2)  =  P[(0i(f  +  l),0i(t),02(<  +  l),03(f  +  2)) 

02(f  +  4)  =  P2(Oi(f  +  4),  02(<  +  3),  03(f  +  3),  03(f))  (3) 

03(<  +  3)  =  P;^(03(f)) 

Moreover  the  initial  values  are  required: 


Oi(0) 

=  ^(1,0) 

02(1)  = 

^(2,1) 

03(0)  =  ^(3,0) 

01(1) 

=  ^(1,1) 

02(2)  = 

^(2,2) 

03(1)  =  ^(3,1) 

02(0) 

=  ^(2,0) 

02(3)  = 

^(2,3) 

03(2)  =  1^(3, 2) 
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03 


Figure  8;  precedence  graph  of  F 


Starting  from  the  system  3  the  precedence  graph  (figure  8)  expressing  that  O2  depends  on  Oi 
and  Oi  depends  on  O3  at  the  same  step  of  time,  is  mechanically  built. 

Then,  a  topological  sort  is  performed  in  order  to  verify  that  the  device  is  correctly  synchro¬ 
nized  (i.e.  that  the  gragh  is  acyclic)  and  in  order  to  produce  a  computation  linear  ordering  of 
the  outputs. 

On  our  running  example,  it  produces  the  following  equations: 

TRLIGHT\{BSl,  BS2){t  +  1)  = 

mux{eqc{TRLIGHTl{BSl,  BS2){t),  orange), 
red, 

mux{eqc{TRLIGHT2{BSl,  BS2){t),  orange), 
green, 

mux(andb(B S l[t) ,  eqc(TRLIGHTl(^BSl,  BS2){t),  green)), 
orange, 

TRLIGHTX{BSl,  BS2){t)))) 

TRLIGHT2{BS1,  BS2){t  -|- 1)  = 

mux{eqc{TRLIGHT2{BSl,  BS2)(t),  orange), 
red, 

mux{eqc(TRLIGHTl(BSl,  B52)(t),  orange), 
green, 

mnx{andh{B S2(t) ,  eqc(TRLI G HT2(B SI,  BS2)(t),  green)), 
orange, 

TRLIGHT2{BSl,  BS2)(t)))) 

Here,  eqc  is  an  identifier  interpreted  by  the  equality  on  the  set  of  colors. 

Then  it  demands  two  initial  values  (one  for  each  output)  resulting  in  a  primitive  recursive 
definition. 

2.2  The  Larch  Proven 

The  LP  proof  assistant  is  a  rewrite  rule  based  tool  which  works  on  a  subset  of  typed  first-order 
logic  with  equality.  The  basis  for  proofs  in  LP  is  a  logical  system  called  a  “theory” .  Theories 
can  be  defined  by  means  of  sorts,  variables,  operators  and  properties  on  these  operators.  Sorts 
are  sets  of  values.  The  properties  on  the  basic  objects  are  axiomatized  by:  equations  which  are 
automatically  oriented  into  rewrite  rules,  operators  theories  (commutative  or  associative  and 
commutative),  deduction  rules  which  are  the  basis  for  generating  new  ecjuations  from  existing 
ones,  induction  rules  defining  a  sort  in  terms  of  bottom  and  constructor  functions. 

A  conjecture  in  LP  is  either  a  deduction  rule  or  an  induction  rule  or  an  equation  of  the 
form  ”  A  ==  B" .  Proving  a  conjecture  consists  in  either  rewriting  it  into  true  or  proving  some 
subconjectures  the  verification  of  which  is  sufficient  to  validate  the  initial  one.  Thus  LP  provides 
two  inference  mechanisms;  backward  and  forward  inference.  The  former  produces  consequences 
from  a  logical  system;  the  latter  yields  a  set  of  subgoals  to  be  proved  in  order  to  validate  a 
conjecture. 
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LP  has  not  been  widely  experimented  in  the  field  of  formal  proof  of  hardware.  The  most 
significant  previous  studies  include:  the  proof  of  circuits  specified  by  means  of  synchronized 
transitions  [11]  and  the  proof  of  a  simplified  ALU  by  validation  of  some  transformations  [21], 
These  approaches  are  based  on  proof  by  cases  and  critical  pairs  computation  but  don’t  involve 
the  LP  proof  by  induction  mechanism. 

2.2.1  Implementing  the  P-calcnlus  into  LP 

To  each  basic  type  in  the  P-calculus  corresponds  in  LP  the  declaration  of  two  sorts,  one  for  the 
type  and  another  one  for  the  temporal  sequences  of  this  type. 

Example: 

For  the  color  type,  we  declare  the  sorts  color  and  sequences  of  color: 
declare  sort  Color,  Color_seq 

The  value  of  a  sequence  at  time  i  is  defined  by  means  of  an  overloaded  operator  dot 
with  the  signature: 

declare  operator  .  :  T_seq,  Natural  ->  T 

Thus,  the  sequences  being  considered  as  objects  instead  of  functions,  second  order  equations 
can  be  expressed  although  LP  only  supports  first  order.  A  wire  of  a  circuit  is  implemented  by 
a  constant  of  a  sequence  sort.  Sequence  vectors  are  implemented  by  their  components. 

Example: 

The  wires  CarOnNS,  CarOnEW,  LEW  and  LN S  of  the  traffic  light  controller  are  implemented 
by: 

declare  operators  CarOnNS,  CarOnEW  :  ->  Bool_seq 
declare  operators  LEW,  LNS  :  ->  Color_seq 

A  functional  variable  F  of  type  S't,  X  •  •  •  x  S't„  — >•  St,  which  is  interpreted  by  a  sequential 
function  /  =  I{F)  is  implemented  by  the  equation: 

(F(X1,  •  ■  Xn)).t  ==  f(Xl.t,  •••,  Xn.t)  where  the  Xi  are  sequence  variables. 

Example: 

The  identifier  AND  will  be  associated  with  the  following  declarations: 

declare  operators  AND  :  Bool_seq,  Bool_seq  ->  Bool_seq 
declare  variables  X,  Y  :  Bool_seq 
assert  AND(X,Y).t  ==  (X.t)  &  (Y.t) 

We  need  to  make  the  distinction  between  the  general  description  of  the  module  ADD  and 
the  description  of  a  particular  instance  of  this  module. 

The  construction  of  a  t-uple  of  modules  is  simply  described  by  the  implementation  of  each 
modules.  In  the  same  way,  the  description  of  the  composition  of  two  modules  is  done  by  the 
implementation  of  the  instance  of  each  module  where  the  outputs  of  one  of  them  are  the  inputs 
of  the  other  one. 

Example: 

The  adder  in  figure  9  is  described  by  the  following  declarations: 

declare  operaror  XOR,  AND,  OR,  HADDl,  HADD2  :  Bool_seq,  Bool_seq  ->  Bool_seq 
declare  operator  ADDl,  ADD2  :  Bool_seq,  Bool_seq,  Bool_seq  ->  Bool_seq 
declare  var  S1,S2,S3  :  Bool_seq 
assert 

HADD1(S1,S2)  ==  X0R(S1,S2) 
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HADD2(S1,S2)  ==  AND(S1,S2) 

ADD1(S1,S2,S3)  ==  HADD1(S1,HADD1(S2,S3)) 

ADD2(S1,S2,S3)  ==  OR (HADD2 (SI .HADDl (S2, S3) ) ,HADD2 (S2 ,S3) ) 

declare  operator  A,B,Ri,S,Ro  ;  ->  Bool_seq 
assert 

S  ==  ADDl(Ri,A,B) 

Ro  ==  ADD2(Ri,A,B) 


BA  Ri 


ADD  =  [SiQHADDq[Su 

SiQHADDq[S2,S3]], 

ORQ[S2QHADDq[Su 

SiQHADDqISo, 

Sz]], 


S2(dHADDQ[S2,Si]]] 


and 

HADD  =  [XOT?©  [51,52], 
ANDq[SuS2]] 


Figure  9:  The  adder 

In  case  of  circuits  with  loops  the  recursive  definitions  are  generated  by  the  interface  (see  2.1). 
Example;  This  is  the  description  of  the  first  output  of  the  traffic  light  controller: 


declare  op 

TRLIGHTl,  TRLIGHT2  :  Bool.seq,  Bool_seq  ->  Color.seq 
CarOnNS ,  CarOnEW  :  ->  Bool_seq 
LEW,  LNS  :  ->  Color_seq 


declare  variables  BSl,  BS2  :  Bool_seq 
TRLIGHTl (BSl, BS2) . (t+1)  == 

MUX(EQ(TRLIGHT1(BS1,BS2) .t,  orange.s.t) , 
red_s.t, 

MUX(EQ(TRLIGHT2(BS1.BS2) .t,  orange.s.t) , 
green.s.t, 

HUX(ET(BSl.t,  EQ(TRLIGHT1(BS1,BS2) .t,  green_s.t)), 
orange.s.t, 

TRLIGHT1(BS1,BS2) .t))) 

TRLIGHT2(BS1,BS2) . (t+1)  == 

MUX(Eq(TRLIGHT2(BSl,BS2) .t,  orange.s.t)  , 
red.s . t , 

MUX (EQ (TRLIGHTl (BSl, BS2) .t,  orange.s.t) , 
green.s . t , 

MUX(ET(BS2,  EQ(TRLIGHT2(BS1,BS2) .t,  green.s. t)), 
orange.s . t , 

TRLIGHT2(BS1,BS2) .t))) 

TRLIGHTl (BSl, BS2) .0  ==  green 
TRLIGHT2(BS1,BS2) .0  ==  red 
assert 

LNS  ==  TRLIGHTl (CarOnEW,  CarOnNS) 

LEW  ==  TRLIGHT2 (CarOnEW,  CarOnNS) 
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2.3  The  Coq  proof  assistant 

2.3.1  A  higher  order  typed  A-Calculus 

The  Coq  system  is  based  on  the  calculus  of  inductive  constructions  [9] .  This  is  a  higher  typed 
A-Calculus  in  which  definitions  of  mathematical  objects  can  be  given  and  proofs  of  propositions 
on  these  objects  can  be  performed.  Both  objects  and  propositions  are  terms  of  the  Lamba- 
Calculus. 

Moreover,  there  are  two  kinds  of  types:  the  propositions  are  of  sort  Prop  and  the  sets  are  of 
sort  Set. 

These  are  the  building  rules  for  the  terms; 

•  identifiers  refer  to  defined  constants  or  to  variables  declared  in  a  part  called  context 

•  {A  B)  denotes  the  application  of  functional  object  A  to  B 

•  [x  ■.  A]B  abstracts  the  variable  x  ot  type  A  in  term  B  in  order  to  construct  a  functional 
object,  that  is  generally  written  Ax  6  A.B  in  litterature 

•  (x  ;  A)B  as  a.  term  of  type  Set  corresponds  to  a  product  JJ  B  of  a  familly  of  sets  B 

indexed  on  A.  As  a  term  of  type  Prop,  it  corresponds  to  Vx  E  A  B.  If  x  does  not  occur 
in  B,  A  — )•  B  is  a  short  notation  which  represents  either  the  set  of  all  the  functions  from 
A  to  B  or  a  logical  implication. 

2.3.2  Induction  principles 
A  typical  example  of  inductive  definition  in  Coq  is: 

Inductive  Set  not  =  0  :  not  \  S  ;  nat  — >  not 

which  defines  the  set  of  naturals  as  the  smallest  set  containing  0  and  its  successors, 
to  this  definition,  the  system  provides  two  elimination  principles: 

•  The  non  dependant  elimination  principle.  A  function  /  :  nat  — >  C  is  defined, 
to  a  primitive  recursive  scheme,  by  means  of  a  given  element  x  of  C  and  a  function 
H  :  nat  C  —>■  C.  f  verifies: 


(/  0)  =  X 

Vn  6  nat  {f{Sn))  —  {H  n  {f  n)) 

Remark:  In  Coq  /  is  written:  [n:nat]  (<C>  Match  n  with  x  H) 

•  The  dependant  elimination  principle  which  corresponds  to  the  well  known  recurrence 
principle.  Let  C  :  nat  — Prop  be  a  predicate.  To  find  a  proof  f  of 'in  E  IN  C{n),  that  is 
to  obtain  a  term  f  :  (n  :  na.t)[C  n),  it  is  sufficient  to  build  two  terms; 

X  :  (C  0) 

B  :  (n  :  nat){C  n)  -4  ((7(5  n)) 


Referring 

according 
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Enumerated  types  can  be  given  by  means  of  non-recursive  inductive  definitions.  For  examjde 
the  type  bool  of  booleans  is  defined  by 

Inductive  Set  bool=  true: bool  |  false: bool 
and  the  type  color  of  the  light  colors  is  defined  by 

Inductive  Set  color  =  red: color  |  orange: color  |  green: color. 

In  these  cases  the  elimination  principles  correspond  to  definitions  or  proofs  by  cases.  For 
example,  the  and  connector  on  booleans  is  defined  by: 

Definition  andb  =  [bl ,b2 :bool] (<bool>  Match  bl  vith 

b2  (*  return  b2  if  bl  is  true  *) 

false) .  (♦  return  false  if  bl  is  false  *) 

and  the  equality  on  the  set  of  colors  is  given  by: 

Definition  eqc : color->color->bool=  [cl , c2 : color] 

(<bool>Match  cl  with 

(*red*) (<bool>  Hatch  c2  with  true  false  false) 

(♦orange*) (<bool>  Hatch  c2  with  false  true  false) 

(♦green*) (<bool>  Match  c2  with  false  false  true)). 

2.3.3  Extracting  programs 

In  this  system,  proving  a  proposition  P,  amounts  to  construct  a  term  of  type  P.  Therefore,  a 
proof  is  a  A-term  and  thus  a  program.  One  of  the  salient  feature  of  Coq  is  the  possibility  of 
extracting  an  algorithm  from  a  proof  [20].  For  example,  an  algorithm  computing  the  natural 
D  can  be  extacted  from  a  proof  of  the  proposition: 

3D/(D  I  a)  A  (D  I  6)  A  (Vd,  (d  [  a)  A  (d  |  6)  ->  d  <  D). 

which  specifies  the  GCD. 

Some  parts  of  the  proof  term  can  be  considered  as  logical  comments,  the  other  parts  being 
purely  computational.  Adequate  declarations  permit  to  make  a  synctatical  distinction  between 
logical  and  computational  parts.  The  extraction  mechanism  consists  in  keeping  only  the  com¬ 
putational  parts,  resulting  in  the  algorithm  correct  by  construction. 

2.3.4  Implementation  of  the  P-calculus  into  Coq 

We  take  advantage  of  the  higher  order  and  define  a  generic  sequence  type,  the  parameter  of 
which  is  a  basic  type. 

Definition  Seq  =[T:Set]  nat->T. 

Thus  (Seq  bool)  is  a  type  of  boolean  sequences. 

The  sequential  function  AND  is  expressed  by: 

Definition  AND  =  [Bl,  B2 : (Seq  bool)] [t :nat]  (andb  (Bl  t)  (B2  t)). 

In  this  way,  we  can  describe  the  half-adder  and  the  adder  in  figure  2  by: 

Definition  Half _Adder= [I, J: (Seq  bool)] (Pair (XOR  I  J) (AND  I  J)). 

Definition  Adder  =[Ri,A,B:  (Seq  bool)] 

(Pair 

(SI  (Half .Adder  Ri  (SI  (Half .Adder  A  B)))) 

(OR 

(S2  (Half. Adder  Ri  (SI  (Half. Adder  A  B)))) 

(S2  (Half. Adder  A  B))))  . 


15 


As  we  did  with  LP,  the  implementation  of  the  traffic  light  controller  uses  the  outputs  gen¬ 
erated  by  the  interface  between  the  P-calculus  and  the  provers.  The  circuit  is  described  by  the 
following  declarations. 


Def init ion  Mux:  =  [b: bool]  [x,y: color]  (<color>Hatch  b  with  (*true*)  x  (*false+)  y) . 
Definition  Output:  nat->color*color=  [t:nat] 

(<color*color>  Match  t  with 
(*0*)  (Pair  red  green) 

(*(Sp)*)  [p:nat] [Previous_Output:color*color]  (Pair 
(Mux  (eqc  (si  Previous_Dutput)  orange) 
red 

(Mux  (eqc  (s2  Previous_Output)  orange) 
green 

(Mux  (andb  (eqc  (si  Previous_Output)  green)  (CarNS  p)) 
orange 

(si  Previous_Output) ) ) 

(Mux  (eqc  (s2  Previous_Output)  orange) 
red 

(Mux  (eqc  (si  Previous_Output)  orange) 
green 

(Mux  (andb  (eqc  (s2  Previous_Output)  green)  (CarNS  p)) 
orange 

(s2  Previous_Output) ) ) ) ) ) . 

Def inition  LEW : (Seq  color) =[t :nat]  (si  (Output  t)). 

Definition  LNS: (Seq  color)=[t:nat]  (s2  (Output  t)). 


2.4  General  ideas  on  the  verification  part 

Our  purpose  in  this  section  is  not  to  compare,  as  it  is  usually  done  in  case  of  fully  automated 
provers,  proof  CPU  times.  This  does  not  make  sense  in  this  context,  since  proof  process  times 
are  insignificant  and  moreover  they  are  negligible  with  respect  to  the  time  required  from  the 
user  for  establishing  mathematical  strategies.  In  addition,  a  proof  in  Coq  is  a  Lambda-term 
which  is  constructed  step  by  step  by  means  of  tactics.  At  the  end  of  the  process,  this  term  is 
saved  and  thus  it  is  available,  if  needed,  without  demanding  the  proof  to  be  run  again. 

We  handled  several  examples  of  synchronous  sequential  circuits  in  both  provers,  investi¬ 
gating  their  potentials  and  taking  advantage  of  their  particular  features  in  order  to  get  proof 
processes  as  general,  as  easy  to  drive,  as  neat,  and  as  understandable  as  possible.  Among  the 
devices  we  studied,  three  of  them  seem  particularly  relevant  in  support  of  our  first  conclusions. 

In  the  case  of  control  dominated  circuits  such  as  the  traffic  light  controller  presented  in  this 
paper,  the  superiority  of  LP  is  undeniable.  This  is  due  to  the  fact  that  in  the  Coq  underlying 
intuitionnist  logic,  a  proposition  is  not  interpreted  by  a  boolean  value  (as  in  the  classical  model 
theory).  Proving  a  proposition  does  not  consists  in  showing  that  the  semantics  value  of  the 
proposition  is  true:  a  proposition  is  a  type  and  proving  it  amounts  to  finding  out  a  lambda 
term  inhabiting  this  type.  Therefore,  boolean  operators  must  be  defined  by  the  user  and  the 
proof  requires  user  intervention  whereas  in  LP,  as  the  boolean  calculus  is  built-in,  the  proof  is 
almost  automatic. 

We  also  verified  a  multiplier  by  iterated  additions  given  in  [12].  In  this  case,  the  proofs  are 
almost  similar  although  Coq  requires  more  expertise  from  the  user.  However,  we  can  take  ad¬ 
vantage  of  Coq  higher  order  for  proving  universal  theorems  that  can  be  applied  for  any  proof  by 
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invariant,  as  it  is  the  case  in  this  example.  This  leads  to  more  general  and  more  complete  proofs. 

The  third  significant  circuit  we  studied  implements  the  well  known  algorithm  of  the  so 
called  egyptian  multiplication.  As  in  the  case  of  the  previous  multiplier,  the  proof  is  classically 
performed  in  LP  by  finding  out  an  invariant  and  by  proving  it.  We  chose  a  radically  different 
approach  with  Coq,  since  we  synthesized  the  circuit  starting  from  its  specification.  One  of  the 
main  points  of  the  synthesis  process  relies  on  an  extraction  of  the  algorithm  from  a  proof,  as 
indicated  in  the  presentation  of  Coq  given  in  the  previous  paragraph.  Among  others  advantages 
of  this  method,  no  invariant  needs  finding  out. 


Conclusion 

In  this  paper  we  focused  on  the  theoretical  part  of  FoRMATH.  This  verification  CAD  system  relies 
on  the  P-calculus,  a  formal  system  interpreted  in  a  functional  algebra.  Well-formed  expressions 
depict  circuit  architectures  and  their  interpretations  correspond  to  the  associated  behaviours. 
The  P-calculus  has  been  completely  described  and  grounded.  Moreover,  an  interface  with 
proof  tools  has  been  defined.  It  essentially  compiles  the  P-expressions,  detecting  loops  without 
registers,  if  any  (in  case  of  sequential  circuits  which  are  not  well-synchronized)  and  removing 
all  occurrences  of  the  past  operator  P.  The  output  is  a  set  of  equations  depending  on  the  time 
and  it  is  straightforwardly  translated  into  primitive  recursive  definitions  in  the  syntax  of  such 
or  such  prover,  provided  a  set  of  initial  register  values  is  given. 

The  main  advantage  of  the  P-calculus  is  that  it  provides  an  uniform  framework  for  for¬ 
mally  describing  and  specifying  circuits,  and  for  performing  behaviour  preserving  algebraic 
transformations  on  them.  Thus,  it  is  a  convenient  tool  in  the  perspective  of  the  “design  for 
verifiability”  which  aims  at  integrating  verifications  at  each  step  of  a  design  process,  going  from 
abstract  specifications  up  to  concrete  implementations. 

In  addition  of  our  current  work  in  the  field  of  the  verification  (including  investigations  on 
proof  and  synthesis  strategies  with  respect  of  several  theorem  provers  and  of  different  kinds  of 
circuits),  our  projects  concerning  the  P-calculus  axe  to  develop  a  bi-directional  translator  be¬ 
tween  the  P-calculus  and  VHDL  to  be  integrated  in  an  user  interface.  Due  to  VHDL  widespread 
use  in  the  international  community,  this  point  cannot  be  evaded  and  demands  a  specific  inves¬ 
tigation  related  to  VHDL  denotational  semantics. 
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Abstract 

Testability  is  an  important  aspect  of  digital  systems  usually  addressed  after  the  design 
phase.  In  this  paper  we  propose  to  take  into  account  testability  constraints  at  the 
beginning  of  this  phase.  We  therefore  propose  a  novel  approach  for  performing  high 
level  synthesis  according  to  area  and  testability  constraints.  Behavioral  testability  metrics 
are  defined  and  used  during  data  path  allocation. 

Furthermore,  we  will  point  out  how  testability  and  area  considerations  are  merged  in  a 
high  level  synthesis  system  to  obtain  a  global  exploration  scheme  of  the  design  space. 
Keywords:  high  level  synthesis,  behavioral  testability,  synthesis  for  testability,  data  path 
allocation. 

1.  Introduction 

This  paper  deals  with  a  novel  approach  for  the  high  level  synthesis  of  digital  systems 
according  to  area  and  testability  constraints. 

Testing  is  one  of  the  most  important  aspects  when  producing  digital  devices.  In  order  to 
take  into  account  testability  features  in  a  high-level  synthesis  process,  we  include 
Behavioral  Testability  Metrics  [1][2]  in  a  high  level  synthesis  system  called  FIDIAS  [3]. 
Testability  considerations  in  FIDIAS  are  inserted  during  data  path  allocation,  so  metrics 
have  to  be  defined  from  data  available  at  that  moment  of  the  design  cycle,  namely:  the 
scheduled  control-data  flow  graph,  SDFG,  and  the  partial  design,  PD  (part  of  the  data 
path  already  allocated). 

For  every  allocation  there  are  usually  several  options,  marked  by  their  increments  on  area 
and  testability.  Testability  metrics  are  used  with  area  estimations  to  select  options  with 
better  testability  area  relationship.  Rules  for  selection  of  allocation  alternatives  that 
increase  testability  are  developed  based  on  the  metrics,  to  fasten  the  search  in  the  design 
space. 

Finally,  a  meta-rule  is  provided  to  combine  area  saving  rules  with  rules  for  controllability 
and  observability  increasing.  It  must  select  which  kind  of  rules  (based  on  area  or 
testability  considerations)  is  used  in  the  first  place.  It  is  founded  on  the  initial  value  of  the 
testability-area  priority  given  by  the  user.  This  initial  value  can  be  modified  by  the  design 
expert  if  either  the  testability  or  the  area  constraint  are  not  satisfied.  As  a  consequence, 
design  exploration  is  flexible  and  can  obtain  designs  with  different  testability-area 
tradeoffs. 

The  paper  is  organized  as  follows.  In  the  first  part,  testability  metrics  are  presented.  The 
second  part  gives  a  brief  overview  of  allocation  in  the  FIDIAS  system;  area-test  tradeoffs 
*  This  research  was  partly  sponsored  by  the  FICM  CHRX-CT94-0459  project  of  the  EC 
and  by  the  CICYT  TIC  94/0725-C03-02  project  of  the  Spanish  Government. 


made  during  design  space  search  are  introduced  in  this  part  also.  In  the  third  part 
present  mil  for  testability  maximization.  First,  the  scheme 

observability  merging  is  detailed  and  then,  the  different  mles  are  explained  with  the  help 
of  some  examples. 

2.  Computation  of  testability  metrics  ,  .  , 

Three  testability  metrics  are  defined,  listed  in  growing  complexity  order,  ^stance-based 
functional  and  reconvergence-divergence.  We  propose  several  ways  to  define  behavioral 
testability  metrics  to  compensate  the  fact  that  they  are  not  y 
computation  of  totally  accurate  metrics  is  known  to  be  an  NP-complete  problem 
would  request  too  much  computational  effort.  ^ 

In  order  to  calculate  these  three  different  metrics,  we  have  defined  two  graph  models 

representing  the  SDFG  and  the  PD.  rwf  +hp 

Next,  the  models  are  defined  in  sub-sections  2. 1  and  2.2  and  then,  computat  o 

metrics  is  outlined  in  sub-sections  2.3,  2.4  and  2.5. 

The  Svior  to  be  allocated  is  shown  as  a  control-data  flow  graph,  made  up  by  nodes 
and  variables  representing  both  control  and  data  dependencies.  Every  node  in  the  graph 
has  been  scheduled  in  one  control  step.  From  the  testability  metric  point  of  view, 

components  ofthe  SDFG  are  divided  into  four  classes; 

•  operational  node  (OPN);  it  represents  a  function  performed  on  the  input  vanable(s), 

■  assignment  node  (ASN):  it  is  a  data  transfer,  i  j  o  cnA  n 

■  divergence:  a  divergence  point  is  a  variable  used  as  rnput  of  several  "0^“  ^  a 
divergence  node  is  either  the  output  of  a  variable  in  a  loop  or  the  input  of  a  vanable  rn  a 

conditional  branch,  ^  ^ 

•  reconvergence  node;  it  is  the  input  of  a  variable  in  a  loop  or  the  output  of  a  vanable  in 

conditional  branch. _ _ 


OPN  node 


(  + 

Divergence 

div.  point 
v1 


v2 


ASN  node 


v^1 


T 

v2 


div.  node;  Loop  Out, 
Branch  In 


Reconvergence  node:  Loop  In, 
Branch  Out 


T 


Functional  unit 
Regl  Reg2 

. hp 

Reg3 

Divergence  point 


Reconvergence  element;  Multiplexer 


Register 

[Regl 


Reg1 


Reg1  Reg2 

FU1(in1) 


Figure  1;  SDFG  model  Figure  2;  DP  model. 

In  figure  1,  a  representative  of  each  class  of  element  is  displayed  with  its  data  (solid)  and 

control  (dashed  lines)  inputs  and  outputs. 

2.2.  Model  of  data  path  ,  ,  ,,  ^  ^ 

Since  the  partial  design  is  the  portion  of  the  data  path  that  has  ^ 

moment,  testability  ofthe  partial  design  has  to  be  based  on  a  mode  ofthe  data  pat  . 
a  set  of  connected  hardware  elements  taken  from  a  library  of  modules. 
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Regarding  testability  computation,  they  are  classified  as  follows  (see  figure  2); 

•  functional  unit  (FU);  element  performing  an  operation, 

■  register:  storage  element.  They  can  be  further  separated  according  to  their  test  abilities 
(test  generators,  compactors,  both  or  none), 

■  divergence  point:  it  represents  a  connection  feeding  several  inputs, 

■  reconvergence  element:  a  multiplexer. 

2.3.  Distance-based  metric 

Testability  of  an  element  is  defined  in  terms  of  its  controllability  and  observability,  that 
are  computed  as  the  closeness  to  controllable  and  observable  elements  respectively. 

So,  controllability  is  the  maximum  closeness  from  any  input  element  and  observability  the 
maximum  closeness  to  any  output  elem.ent.  They  are  measured  in  number  of  nodes  and 
hardware  elements  for  the  SDFG  and  PD. 

The  closeness  between  to  elements  Ej  and  E?  is  derived  from: 


Closeness(Ei,E2) 


Distance(Ei,E2) 
1  +  Max.  distance 


where  Distance(Ei,E2)  is  the  minimum  number  of  elements  traversed  to  reach  E2  from 
Ej  and  Max.  distance  is  the  maximum  distance  along  the  DFG  or  DP. 

The  maximum  distance  has  been  defined  for  the  DFG  as  the  number  of  control  steps 
minus  one.  This  definition  is  based  on  the  hypothesis  that  there  is  a  path  connecting  an 
element  in  the  first  control  step  to  one  in  the  last  control  step  and  that  such  a  path  has  a 
node  in  each  control  step.  It  is  a  reasonable  choice  because  it  is  easy  to  compute  and 
quite  accurate  since  most  schedules  are  minimal  or  nearly  minimal  (high  level  synthesis 
tools  rarely  increase  the  number  of  control  steps  and,  when  doing  so,  they  only  add  1  or 

The  maximum  distance  in  the  data  path  is 
computed  alike:  a  non  cyclic  path  from  an 
element  used  in  the  first  control  step  and 
another  used  in  the  last  one  is  assumed  and  no 
wait  control  steps  are  allowed  in  it. 

But,  this  time  the  number  of  hardware  elements 
traversed  in  a  control  step  is  variable  from  1 
(only  a  register)  to  4  (a  multiplexer  at  the  input 
of  a  FU,  the  FU,  a  multiplexer  at  the  input  of  a 
register  and  the  register).  Since  the  complete 
data  path  is  not  known  until  the  end  of  the 
allocation  process,  the  number  of  elements  that 
make  up  each  path  cannot  be  known.  So  an 
additional  assumption  is  needed:  the  maximum 
(4)  is  used  as  number  of  elements  in  one 
control  step.  Then,  the  maximum  distance  is  computed  as  four  times  the  number  of 
control  steps  minus  one. 

Distance  computation  for  every  element  is  done  by  the  algorithms  shown  in  figures  4 
(distance  to  an  output  element  needed  for  observability  computation)  and  5  (distance 
from  an  input  element  required  to  obtain  controllability).  An  example  of  testability 


from  input  elements  are  shown.  On  the 
right,  distances  to  output  elements. 
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computation  for  a  DFG  commonly  used  in  high  level  synthesis  (the  differential  equation 
solver  in  [4])  is  displayed  in  figure  3. 


dist(Out)  =  0; 

From  control  step  N  to  I 

dist-inJ(OPN)  =  dist-out(OPN)  +1  VJ 
dist-in(ASN)  =  dist-out(ASN)  +1 
dist-in(div.  point)  =  min  {dist-ouU(div.  point)} 
dist-in(div,  node)  =  min  {dist-outJ(div.  node)}  +1 
dist-inJ(rec.  node)  =  dist-out(rec.  node)  +1  VJ 
Check,  on  loops 


Figure  4;  Distance  to  Out  computation. 


dist(In)  =  0; 

From  control  step  1  to  N 

dist-out(OPN)  =  max  {dist-inJ(OPN)}  +1 
di.st-out  (ASN)  =  dist-in(ASN)  +1 
dist-outJ(div,  point)  =  di.st-in(div,  point)  VJ 
dist-outJ(div.  node)  =  dist-in(div.  node)  +I  VJ 
dist-out(rec,  node)  =  min  {dist-inJ(rec,  node)}  +1  J. 

Check  on  loops 


Figure  5:  Distance  from  In  computation. 
1  Control  lines  are  fully  controllable. 

2.4.  Functional  metric 

Testability  is  no  longer  dependent  on  the  number  of  elements  but  on  their  operation. 

Since  functional  metrics  only  take  into  account  the  functionality  of  elements  traversed, 
testability  is  modified  only  for  operational  elements  (OPN  nodes  or  functional  units). 
Thus,  the  controllability  of  the  output  of  an  element  is  the  same  as  the  one  of  the  input 
except  for  operational  elements.  For  them,  the  controllability  is  computed  as  the  product 
of  the  controllability  of  the  input  by  the  control  transfer  factor  of  the  operator  (CTF).  It 
represents  the  fraction  of  data  that  can  be  reached  at  the  output  for  that  operation 
(cardinal  of  the  operator's  image  set  divided  by  all  possible  values). 

Observability  of  input  k  is  computed  quite  alike,  save  that  not  only  the  observability  of 


the  output  is  included  but  also  the  contro 


obs(Out)  =  1; 

From  control  step  N  to  1 

obs-inJ(OPN)  =  obs-oiit(OPN)  »  OTF(oper.itor) 

*  min  {co-inK(OPN)}  VJ 
obs-in(div.)  =  max  {obs-outJ(div.  point)} 
obs-in(rest)  =  obs-out 

OFT(operator)  =  fraction  of  non  dominant  values  in  the 
domain  set  of  the  operator.  A 


Figure  6:  Observability  computation. 


labilityofinpuH^lc 


co(ln)  =  1; 

From  control  step  1  to  N 

co-out(OPN)  =  min  { co-in  J(OPN)}*CTF(operator) 
co-out(rec.  node)  =  max  {co-inJ(rec.  node)} 
co-out(rest)  =  co-in 

CTF(operator)  =  fraction  of  all  binary  cordlgurations  in 
the  image  set  of  the  operator.  * 


Obs. 

OTF(or)  =  0.5 
OTF(t)  =  1 


Co. 

CTFC)  =  0.35 
CTF(+)  =  1 


obs  =  0.18 


pbs  =  0.5  . 


T*’ 


I - CO  =  1 


X  —  .»v6 

(  *  ) 

«'■ . 


X  — 

(■). 


Figure  7;  Controllability  comp.  (F). 

♦  They  are  computed  by  simulation. 
Algorithms  for  observability  and  controllability 
computation  are  shown  in  figures  6  and  7 
respectively.  Their  application  to  a  high  level 
synthesis  example  (the  Facet  DFG  in  [5])  can  be 
seen  in  figure  8. 


,CO  =  1 


( i 


obs  =  1 


(« 


i: 

^  Mid 


CO  =  0.35 

and 


co(ln)  =  1 ; 

From  control  step  1  to  N 

co-out(OPN)  =  min  {co-inJ(OPN)} 

•  CTF(operator)  ♦  CD(OPNnode) 
co-out(rest)  =  like  functional  metric 
CD(OPNnode)  =  fraction  of  output  values  reachable  in 
spite  of  data  dep.  between  inputs. 


Figure  8:  Facet  DFG. 


Figure  9:  Controllability  computation  (R-D). 


2.5.  Reconvergeiice-divergence  metric 

Finally,  reconvergence-divergence  metrics  take  into  account  the  effect  that  data 
dependencies,  due  to  divergences  that  later  reconvert,  have  on  the  controllability  of 
different  inputs  of  an  operational  element.  Then,  with  this  more  precise  controllability 
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figure  (see  figures  9  and  10  for  details), 
controllability  of  the  output  of  an  operational 
element  and  observability  of  every  input  are 
computed  as  for  the  functional  metrics. 

Due  to  its  big  complexity,  this  metric  is  only 
applied  to  the  SDFG.  The  reason  is  that 
testability  of  the  SDFG  is  computed  only  once 
(before  allocation)  while  testability  of  the  PD 
must  be  estimated  every  time  an  allocation 
choice  is  taken. 


Figure  10:  Facet  DFG 


3.  Search  guiding  in  allocation 

Allocation  in  FIDIAS  uses  a  branch  and  bound  algorithm  that  allows  exploration  of 
different  designs  for  the  same  behavior.  The  sequence  in  which  these  designs  are  found 
determines  the  search  time.  In  order  to  reduce  exploration  time  some  heuristics  are 
defined.  Their  goal  is  that  the  best  data  paths  in  terms  of  testability  and  area  are  obtained 
as  soon  as  possible.  The  method  we  have  defined  sorts  out  the  list  of  alternatives  for 
each  allocation  (that  is,  the  list  of  functional  units  for  an  operational  node  and  the  list  of 
registers  for  storage  of  results)  using  the  heuristics.  The  result  is  that  alternatives  with 
better  testability  and  area  are  the  first  elements  to  be  tried  in. 

Good  designs  correspond  to  designs  having  big  testability  and  small  area.  They  are 
reached  when  allocation  decisions  produce  testability  increments  (gam)  that  are  worth 
their  counterpart  area  increment  (cost). 

For  any  allocation  alternative,  area  increment  is  computed  using  the  estimation  explained 
in  [6].  The  testability  increment  caused  by  each  alternative  is  obtained  as  follows:  first, 
controllability  increment  for  all  the  inputs  and  observability  increment  for  the  output  are 
computed  according  to  the  metrics  above  introduced,  and  then,  the  maximum  among  the 
increments  is  selected  as  testability  increment. 

When  design  search  is  over,  one  data  path  is  selected  as  best  due  to  its  area  and  test 
figures.  Users  should  be  allowed  to  establish  the  area-test  priority  for  their  designs.  The 
best  design  according  to  the  user  criterion  is  the  one  with  area-testability  ratio  that  suits 
the  user  given  priority.  Thus,  to  obtain  that  design  as  quickly  as  possible,  the  order  in 
which  alternatives  are  explored  should  also  be  determined  by  the  area-test  priority  (p).  It 
represents  the  degree  of  test  importance,  so,  when  it  takes  a  value  close  to  0,  area  is 
much  more  important  than  test,  while  figures  close  to  1  lead  to  test-driven  searches. 

To  sum  up,  search  time  is  saved  if  designs  explored  have  good  test-area  relationship,  so 
allocation  decisions  need  to  have  good  gain-cost  ratio.  Further,  selection  of  the  best 
design  depends  on  the  user  criterion,  and  so  does  search  guiding. 


3.1.  Global  exploration  scheme 

Search  guiding  is  performed  by  application  of  area  and  test  rules,  that  sort  out  the  list  of 
available  elements  according  to  minimum  cost  and  maximum  gain  respectively. 

Testability  increment  rules  and  the  area  saving  rule  have  to  be  merged  in  a  unique 
exploration  heuristic.  So,  a  meta-rule  is  needed  to  decide  between  area  saving  and 
testability  increasing.  This  meta-rule  fixes  the  search  order,  so  that  it  determines  how  the 
design  space  is  searched. 
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The  underlying  idea  is  that  cost  (area)  is  spent  if  the  gain  (testability  inc.)  is  worth  it.  The 
gain  is  worth  if  it  is  bigger  than  the  opposite  of  the  area-test  priority  so  that  the  more 
important  the  area,  the  larger  the  gain  required  to  spend  it. 

Let  P  be  the  area-test  priority,  and  ATe[0,l]  the  testability  increment  (either  in 
controllability  or  observability).  If  testability  increment  is  bigger  than  1  -  P,  test  rules  are 
applied  first.  Else,  area  rule  is  applied  first.  So,  if  p  is  close  to  0,  the  area  rule  would  be 
applied  in  the  first  place  unless  testability  increment  was  close  to  1.  On  the  other  hand, 
bigger  values  of  p  cause  selection  of  testability  rules  for  smaller  gains. 

As  a  result  of  this  scheme,  the  search  should  be  speeded  up  because  the  searching 
criterion  matches  the  quality  criterion.  Besides,  design  space  exploration  is  flexible  and 
can  vary  according  to  the  user  preferences.  Finally,  if  the  constraints  are  not  met  for  a 
given  value  of  the  user  criterion,  the  design  expert  can  change  that  value  to  search  for  a 
valid  design.  This  capability  allows  smart  search  of  a  wider  design  space. 

4.  Testability  increasing  rules 

They  order  allocation  choices  according  to  the  testability  increment  implied.  These  rules 
are  also  twofold;  controllability  and  observability  rules.  Controllability  rules  order  the  list 
of  alternatives  (functional  units  or  registers)  according  to  the  controllability  increment 
that  would  be  caused  by  selection  of  the  alternative.  Observability  rules  work  in  the  same 
way  with  regard  to  observability  increment. 

Controllability  and  observability  rules  have  to  be  merged,  that  is,  for  a  given  allocation, 
the  order  in  which  both  testability  rules  are  tried  in  must  be  established.  The  merging 
scheme  is  to  apply  the  rule  that  leads  to  maximum  increment.  If  they  produce  the  same 
gain,  the  controllability  rule  is  preferred  because  observability  depends  on  controllability 
and  not  the  other  way  around. 

4.1.  Controllability  rules 

They  are  aimed  at  sorting  out  the  list  of  available  elements  (FU  or  registers)  according  to 
their  controllability  increments.  There  are  some  different  rules  depending  on  the 
controllability  of  the  connection's  source(s);  a  controllable  source  improves  the 
controllability  of  the  element  chosen  as  destination.  So,  the  less  controllable  the 
destination  element,  the  larger  the  controllability  increment.  An  example  is  shown  in 
figure  1 1,  where  a  register  must  be  selected  to  store  data  from  an  input  port. 

On  the  other  hand,  if  the  source  of  data  is  not  controllable,  connecting  it  to  an  element 
will  not  improve  the  controllability  of  the  source  element.  But,  choosing  a  controllable 

element  will  improve  the  controllability  of  the 
variable.  If  this  variable  is  later  used  as  input,  it 
will  be  more  controllable  and  some  controllability 
increment  will  be  achieved.  In  figure  12  the  source 
element  is  a  non  controllable  FU  output.  If  a 
controllable  register  is  connected  to  it,  the  result 
generated  by  the  FU  becomes  controllable. 

To  specify  more  precisely  the  rules,  lets  assume 
that  an  element  is  controllable  if  its  controllability 
is  bigger  than  p.  Thus,  the  controllability  value 


I  ^  I  co(IN-out)  =  1  Aco;  reg 

^co(regl)  =  0.95 

□ 

^obs(reg) 

Aco  =  0.05 


Figure  1 1 :  elements  involved  in  reg. 
selection  for  the  output  of  IN. 
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required  for  an  element  to  be  controllable  is  proportional  to  the  test  importance. 

If  the  source  of  data  is  controllable,  the  following  rule  is  applied:  controllability 
increment  for  each  alternative  is  computed.  If  no  controllability  increment  is  big  enough, 
it  means  that  controllability  of  the  source  is  wasted  (all  available  elements  are  already 
controllable).  So,  creation  of  a  new  element  is  considered  based  on  area  increment, 
number  of  elements  in  the  partial  design  and  estimated  minimum  number  of  elements  in 
the  complete  data  path  and  on  the  impact  of  creating  a  controllable  element  (it  is, 
whether  or  not  the  element  will  be  further  used). 

Else,  elements  are  selected  to  maximize  controllability  increment.  Elements  producing 
the  same  increment  are  sorted  out  following  the  observability  rule. 

Rule  for  register  selection  is  introduced  as  example  in  figure  13,  where  out  means  the 


Next,  situation  shown  in  figure  1 1  is  used  to  illustrate  the  rule.  Let  (5  =  0.4  (area  is  a  little 
more  important  than  test),  the  order  registers  are  tried  in  according  to  the  controllability 
rule  is:  first,  register  2,  then  register  1  and  the  third  choice  is  creating  a  new  register. 

If  (5  =  0,6,  the  first  choice  would  be  creating  a  new  register  (Aco  =  1)  and  only  after, 
registers  2  and  finally  1  would  be  tried  in. 

4.2.  Observability  rules 

Their  difference  from  controllability  rules  comes  from  the  fact  that  observability  is 
transmitted  from  the  last  to  the  first  control  steps,  that  is,  opposite  to  allocation  flow. 
This  means  that  when  an  allocation  has  to  be  made,  the  controllability  of  the  source 
element  is  known  (paths  from  input  ports  to  that  element  have  already  been  allocated). 
On  the  contrary,  observability  of  the  destination  element  is  only  determined  when  a  path 
to  an  output  element  is  created,  usually  in  the  last  control  steps.  Thus,  not  only 
observability  of  the  output  is  considered  but  also  observability  of  the  variable  in  the 
SDFG  (if  it  is  big,  a  path  to  an  output  port  will  be  created  in  the  following  control  steps). 
So,  according  to  the  observability  of  the  output  variable  (in  the  SDFG)  there  are  different 
rules:  if  the  variable  is  observable,  it  will  improve  the  observability  of  the  element  chosen 
as  destination.  In  such  cases,  the  less  observable  the  destination,  the  bigger  the  gain,  as 
displayed  in  figure  14  for  FU  selection. 

On  the  other  hand,  a  non  observable  variable  does  not  necessarily  imply  that  the  source 
of  the  connection  is  not  observable.  So,  two  more  rules  are  needed  for  the  two  remaining 
possibilities.  If  both  the  source  of  the  connection  and  the  variable  are  not  observable,  an 
observable  destination  is  searched  to  improve  their  observability  (see  figure  15). 


If  co(out)  >  P 

for  all  available  registers  (regl) 

Acol  =  co(oiit)  -  CO  (regl) 
if  (Acol  -  p,  VI)  &  (ncw_reg  =  TRUE) 
create  new  register 

else 

select  reg  for  maximum  Aco 
if  several,  apply  observability  rule 
if  there  are  no  free  register,  create  new _ 

Figure  13:  controllability  rule  for  register 
selection  when  the  source  is  controllable. 


output  of  the  source  element. 

j co(fu-out)  =  0.25  Aco:  vsr 
TV  V 


co(v)  =  0.95 _ co(v)  =  0.5 _ co(v)  =  0.25 


Figure  12:  elements  involved  in  register 
selection  for  the  output  of  FU. 
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Figure  14;  elements  involved  in  FU  Figure  15:  elements  involved  in  FU 
selection  when  the  variable  is  observable,  selection  for  a  non  observable  node. 

Finally,  if  the  variable  is  not  observable  but  the  source  is,  no  observability  gain  is  got  by 
selection  of  an  observable  destination,  so  the  less  observable  ones  are  chosen. 

The  rule  applied  for  observable  variable  is:  observability  increment  is  computed.  If  no 
increment  is  big  enough  and  trying  to  avoid  observability  waste,  creation  of  a  new 
element  is  considered.  Else,  the  list  of  elements  is  arranged  to  maximize  observability 
increment.  Equal  increments  are  sorted  out  by  using  the  controllability  rule. 

Application  of  this  rule  to  figure  14,  results  in  selection  of  FU  1  in  the  first  place. 

5.  Conclusions  and  future  work 

An  scheme  for  the  automatic  synthesis  of  data  paths  has  been  outlined.  It  is  based  on 
testability  metrics  that  are  defined  in  a  consistent  way  on  the  circuit's  structure  (data 
path)  and  behaviour  (SDFG),  so  that  testability  of  the  unallocated  part  of  the  circuit  is 
obtained  from  the  second. 

Integration  of  these  metrics  in  the  allocation  step  of  a  high  level  synthesis  tool  has  also 
been  proposed,  in  such  a  way  that  it  drives  exploration  of  the  design  space.  Area  and  test 
guiding  make  exploration  shorter  and  adaptable  to  different  user  priorities. 
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Abstract 


Benchmarking  in  High-Level  Synthesis  is  one  of  the  most  critical  points  nowadays. 
Since  several  synthesis  and  data  path  allocation  methods  are  published,  the  comparison 
between  these  methods  is  highly  important.  The  goal  of  this  paper  is  to  summarise  the  basic 
steps  of  the  HLS  design  flow  trough  the  PIPE  synthesis  tool  integrated  into  the  Cadence 
environment,  which  has  been  developed  at  the  Department  of  Process  Control,  arid  tp 
describe  some  of  the  most  popular  HLS  benchmarks.  This  paper  also  presents  the  basic 
definitions  of  the  DFGs  elements  (fiinctional  elements,  data  connections),  which  are  used  as 
the  description  of  the  task.  These  definitions  are  indispensable  for  the  correct  comparison. 


Key  words: 

High-Level  Synthesis,  Cadence,  benchmarks 


Glossary 


Data  path  -  A  directed  graph  representation  of  data  transitions  in  a  problem.  Graph  nodes 
are  operations,  edges  are  data  connections  and  dependencies. 


Execution  time  -  Time  needed  by  an  (elementary)  operational  unit  to  calculate  its  output 
value  from  its  inputs.  Denoted  by  t(i),  where  i  is  the  number  of  the  operation. 

Latency  -  Time  difference  between  a  set  of  data  entering  the  data  path  and  the  output 
values  belonging  to  that  set  of  input  data  becoming  available  on  the  outputs.  (L) 


Loop  or  Recursive  loop  -  A  section  in  a  data  path  executed  in  an  iterative  way  such  that 
every  iteration  requires  the  result  of  the  previous  iteration  (as  initial  value)  and  data  from 
the  data  path.  As  the  time  between  successive  iterations  of  the  loop  may  not  be  smaller  than 
the  total  of  all  execution  units  in  the  loop  (Lj-),  the  loop  takes  data  from  the  outside  at  most 
with  the  frequency  equal  to  l/Lj.. 


Pipelined  execution  -  Feeding  a  system  with  a  restart  time  less  than  total  latency  is 
available  in  some  units.  Any  such  unit  is  executing  in  an  overlapped,  pipelined  way. 


Restart  time  -  The  period  time  of  new  data  input  to  the  system.  (R) 


Time  steps  or  Time  cycles  -  The  time  unit  in  time  calculations,  often  expressed  without 
dimension,  i.e.  "a  time  of  3  [time  cycles]". 


Functional  Element  (e(i)  or  Fej): 

1 .  e(i)  is  started  only  after  having  finished  every  e(j),  for  which 
e(j)— >e(i)  (where  e(j)  is  the  predecessor  of  e(i))  holds. 

2.  e(i)  requires  all  its  input  data  during  the  whole  duration  time  t(i) 

3.  e(i)  may  change  its  output  during  the  whole  duration  time  t(i) 

4.  e(i)  holds  its  actual  output  stable  until  its  next  start. 
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1. 


Introduction 


The  last  few  years  the  High-Level  Synthesis  has  become  a  very  popular  research 
field  where  several  methods  were  published  [1,3,4,6-8,11,13,14].  The  common  goal  of 
these  methods  is  to  find  an  efficient  structure  at  the  RTL  level  from  a  behavioral  -mostly 
VHDL  or  VHDL-like-  description  with  an  acceptable  computation  time.  Since  the  substeps 
of  the  HLS  are  NP-hard  problems  the  question  of  the  processing  time  is  always  solved  by 
introducing  restrictions  which  results  in  near-optimal  solutions.  The  data-flow  graph  (DFG) 
synthesis  has  two  basic  tasks.  First,  the  scheduling  whose  goal  is  to  place  the  functional 
elements  to  the  control  step  where  the  concurency  is  minimal.  Second,  the  allocation  that 
aims  to  minimise  the  number  of  the  needed  functional  units  (adder,  multiplier,  devider, 
ALUs  or  processors).  A  well-known  strategy,  and  maybe  the  one  that  is  referred  most  of  the 
time  is  the  force-directed  scheduling  [8]  which  proposes  to  reach  the  most  efficient 
structure  by  balancing  the  mobilities  in  the  DFG.  Another  approach  to  synthetise  DFGs  are 
the  ILP  methods.  Generally  these  methods  can  handle  only  single  cycle  operations  [4],  but 
there  are  some  known  expansion  for  multi-cycle  operations  too  [17].  The  only  thing  that  all 
of  the  mentioned  methods  accept  is  that  all  the  problems  that  can  arise  during  the  HLS 
design  flow  are  solved  inside  of  the  DFG.  Opposed  to  this  very  important  point,  there  are 
some  published  CDFG  (control  data-flow  graph)  oriented  methods  where  external  elements 
-or  signals-  are  admissible  [10,14].  These  methods  usually  lead  to  a  heuristic  direction,  and 
this  strongly  makes  the  comparison  to  the  optimal  solution  more  difficult  (since  the 
optimal  solution  is  unknown). 

Another  feature  of  the  HLS  is  the  overlapped  execution  called  pipelineing.  The  goal 
of  the  DFG  pipelineing  is  to  increase  the  throughput  of  the  system  (reduce  the  restarting 
period),  while  the  number  of  resources  is  still  held  on  the  minimal  value.  To  compare  the 
results  of  the  HLS  tools  which  can  handle  pipeline  restarting  period  is  much  more  difficult 
than  in  the  case  of  non-pipelined  ones.  Even  the  basic  definitions  can  be  very  different  in 
different  articles.  Some  researchers  use  the  notion  of 'pipeline  stages'  [8,10],  while  others 
use  'restarting  period'  [1-3,9-12],  in  some  articles  the  'latency'  is  the  period  time  of  new  data 
input  to  the  system,  but  somewhere  else  it  is  called  'restart  time'.  However,  the  fundamental 
problem  is  in  the  physical  domain  of  the  design.  In  contrast  to  the  'old  axiom'  stating  that 
during  the  HLS  we  don't  deal  with  the  physical  constraints,  some  of  the  physical  parameters 
still  have  to  be  defined  before  the  design-flow  starts.  The  execution  times  have  to  be 
defined  (they  are  inputs  in  every  methods),  and  for  the  comparable  results  the  rate  of  the 
speed  must  be  defined  too.  That  is  the  point  where  the  number  of  the  various  views  is 
nearly  equal  to  the  number  of  the  articles  if  these  problems  are  discussed  at  all.  Pipelineing 
raises  some  special  questions  too: 

•  What  to  do  with  recursion?  [9] 

•  How  is  it  possible  to  handle  the  conditional  branches?  [10,1 1] 

The  answers  have  been  worked  out  usually  independently  without  specifying  the  scheduling 
or  the  allocation  algorithms,  but  some  approaches  [10]  use  the  'single  cycle  functional 
elements'  restriction  again. 

Since  so  many  researchers  work  in  so  many  ways,  in  order  to  solve  the  questions  of 
HLS  it  is  highly  important  to  find  a  common  base  and  a  common  language  where  a 
comparison  can  be  made  between  the  different  results.  In  this  paper,  a  technique  for  DFG 
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synthesis  will  be  presented,  also  some  benchmarks  will  be  shown  that  might  be  suitable  for 
testing  different  HLS  tools. 

2.  PIPE 

The  PIPE  is  an  educational  software  tool  that  has  been  developed  at  the  Teclmical 
University  of  Budapest,  Department  of  Process  Control.  The  input  of  the  program  is  an 
HDL  specification  of  the  design  and  the  output  is  a  trade-off  between  the  restarting  period 
and  the  needed  area  (the  number  of  the  processors)  with  fixed  maximal  latency,  hr  the  first 
step  the  HDL  is  translated  into  an  inner  structure.  The  translator  contains  a  schemantical 
checking  function.  The  minimum  of  the  latency  is  calculated  in  this  step.  The  '  Variation  ' 
generates  all  the  possible  placements  for  the  synchronisation  buffers,  and  pushes  it  towards 
to  the  allocation  one  by  one.  The  allocation  is  done  for  each  structure,  and  the  decision 
about  the  optimum  is  just  made  when  all  results  are  known. 

•  Scheduling 

This  algorithm  is  executed  when  the  difference  between  the  latency  minimum  and 
the  given  latency  allows  the  buffer  insertion  discussed  in  [12]  .  The  scheduler  schedules 
the  structure  for  the  given  restarting  period  and  calculates  the  synchronisation  parameters. 
While  a  buffer  is  cheaper  than  an  other  copy  from  a  functional  elements,  this  scheduler 
algorithm  guaranties  the  cheapest  structure  which  is  restartable  with  the  given  restarting 
period. 

for  i  (every  elements) 

if  t(i)>=R-l  then  c=[t(i)+2/R]  ; 

multiply  c  times  ; 

insert  a  buffer  to  every  input  of  every  copy  ; 
else  for  j  (every  next  elements  in  data  connection) 

if  t(i)+t(j)>=R-l  then  insert  a  buffer  between  e(i)  and  e(j) 
next] 

if  e(i)  receptor  then  SYNC  [12] 

next  i 

•  Variations 

The  Variations  generates  all  the  possible  placement  of  the  buffers  was  inserted  to 
solve  the  synchronisation  problem.  This  means  that  all  the  functional  units  have  mobility 
in  the  DFG  go  through  all  the  time  steps  between  there  ASAP  and  ALAP  position.  The 
best  arrangement  will  result  the  cheapest  final  structure  after  the  allocation.  If  the  i^^  path 
needed  to  be  delayed  by  inserting  p(i)  buffers  and  the  path  contains  n(i)  elements,  then  the 
number  of  the  possible  variations  is: 
w(i)=(p(i)+n(i)) !  /(p(i) !  *n(i) ! ) 

The  number  of  the  variations  for  the  whole  graph  is: 

W=n  w(i) 
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for  i  (every  path  which  needed  to  be  delayed) 

for  j  (every  placement  between  ASAP  and  ALAP) 

generate  a  new  variation 

next) 

next  i 


•  Allocation 

The  allocation  algorithm  follows  the  method  which  was  detailed  in  [1,12].  In  this 
step  the  program  selects  the  functions  which  can  be  slipped  into  one  processor  and  solves 
the  allocation  problem  for  each  group.  During  the  allocation  three  tasks  are  executed; 
Concurencv  examination:  in  this  step  the  allocation  checks  all  functional  elements  if 
they  are  concurrent  or  not. 

Generating  the  maximal  compatibility  groups 

Coverage:  here  the  allocation  chooses  the  cheapest  set  of  groups  from  the  maximal 
compatibility  groups. 

•  Analysis  of  Conditional  Branches 

If  the  DFG  contains  conditional  branches  (if-then-else  statement),  the  allocation 
should  be  modified.  The  difference  between  a  condition-detector  element  and  a  general 
element  is  that  just  one  of  the  following  transfer  sequences  executes  depending  on  the 
condition  value.  Since  two  parallel  branches  have  EXOR  like  execution  the  concurency 
examination  must  be  changed.  The  new  formula  is  [11]; 


where, 


K  -  [(c(y)  *  k,  U)  +  h)-  (c(i)  *  ii)  +  s)]*R 
b(0  - Kj) - q{j)  b(i) - b(J)  +  q(i) 


b(i),  b(j) 
c(i),  c(j) 
kh(i).  ks(i) 
R 

q(i),  qG) 


the  first  start  time  of  e(i)  and  e(j) 
the  copied  number  of  e(i)  and  e(j) 
a  integer  values 
the  restarting  period 
the  transfer  score  of  e(i)  and  e(j) 


more  detailed  definitions  in  [1]. 


In  case  of  alternative  branches,  the  K— 0  solution  doesn't  mean  concurency  for  the 
functional  element  pairs. 

•  Pipelineing  in  multi-user  sequential  recursive  loops 

Recursive  loops  are  considered  to  be  unavailable  to  overlapped  execution  during  the 
scheduling  phase  of  ASIC  design.  This  is  caused  by  the  special  nature  of  recursive 
execution:  an  iterative  algorithm  may  not  be  fed  the  next  data  before  the  final  result  of  the 
previous  iteration  is  ready.  In  contrast  with  this  fact  there  are  numerous  papers  [6,8]  which 
use  pipelined  recursive  loops  as  benchmarks.  The  most  popular  one  is  the  differential 
equation  solver  [8].  The  mathematical  definition  (1)  of  this  problem  shows  clearly  the 
recursive  nature. 

xl=x+dx;  yl=y+dy;  ul=u-3xudx-3ydx  (1) 
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In  [8]  Paulin  schedules  the  DFG  (  see  in  3.4  )  for  overlapped  execution  without  dealing 
with  the  recursion. 

There  are  some  notable  exceptions,  however,  to  the  general  case.  In  a  special  type  of 
problems,  recursive  solutions  are  needed  to  calculate  values  of  identical  functions  for 
different  processes.  From  [9],  it  is  known  that  by  using  multiple-process  recursive  loops,  it 
is  possible  for  separate  processes  to  share  the  same  resources  in  such  a  way  that  the 
recursive  core  in  process  is  realised  only  once.  It  means  that  the  total  loop  sequence  will  be 
divided  into  smaller  parts  where  each  part  can  work  parallel  on  a  task  and  the  parts  rolling 
through  the  loop  without  breaking  the  rule  of  the  recursion  (pipelined  recursive  loop).  Also 
from  [9]  can  be  read  out  the  conditions  when  it  is  worth  using  this  method: 


L.  n 

The  right  side  of  ( 2  )  shows  that  the  more  the  restarting  period  is  decreased  against  the 
latency,  the  more  efficient  structure  will  be  achieved  and  from  the  left  side  it  can  be  seen 
that  as  more  and  more  data  is  introduced  to  the  structure,  the  result  can  be  more  and  more 
efficient. 

3.  Tool  integration  into  commercial  frameworks 

State-of-the-art  CAD  systems  should  provide  more  and  more  aid  for  the  electronic 
designers.  This  means  that  a  good  design  system  should  support  consistent  descriptions  in 
all  design  description  domains  (system  specification,  behavioral,  structural  and  physical 
levels)  and  integrated  tools  for  the  simulations  and  for  the  verifications.  It  is  also  required  to 
automate  the  design  steps  as  much  as  possible  to  reduce  the  needed  development  time  and 
hence  the  cost  of  engineering. 

Modem  CAD  systems  can  accomplish  these  tasks  with  providing  consistent 
database  management  and  access,  powerful  communication  protocol  for  the  different  kind 
of  tools  and  user  friendly,  uniform  graphics  environment  for  the  user.  This  complex  system 
is  called  framework.  In  most  cases  it  may  be  extended  by  programming  in  a  vendor 
dependent  language.  Nowadays  the  simulation  procedure  is  one  of  the  most  critical  points 
of  the  design  process.  Of  course  all  description  domains  have  to  be  simulated  with  the  same 
simulator,  if  possible.  In  this  case  the  electronic  designer  can  apply  the  same  test  vectors  (or 
with  minor  modifications)  which  increases  the  reliability  of  simulation  and  simultaneously 
reduces  the  required  development  time.  The  framework  should  provide  the  back  annotation 
feature  to  improve  the  accuracy  of  the  descriptions  at  the  higher  abstraction  levels.  Finally, 
CAD  systems  should  support  the  available  ASIC  technologies  (FPGA,  VLSI  and  MCM). 

When  a  new  design  methodology  has  been  developed,  it  is  recommended  to  connect 
to  an  existing  framework  environment,  unless  we  wish  to  create  a  completely  new  CAD 
system.  Since  in  most  cases  the  new  tool  covers  just  a  few  design  steps  thus  probably  the 
extension  is  the  better  choice  and  it  requires  less  effort. 

A  special  type  of  the  extensions  is  the  interfacing.  In  this  case  the  new  CAD  tool  is 
not  a  part  of  the  framework  environment,  just  a  standalone  application  that  has  a  well- 
defined  interface.  This  interface  is  usually  a  standard  hardware  description  language 
(VHDL  or  Verilog),  a  netlist  format  (EDIT)  or  physical  description  file  (for  VLSI  layouts 
CIF,  GSDn,  etc.)  depending  on  the  abstraction  level.  Interfacing  has  several  disadvantages. 
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First  of  all,  it  does  not  provide  a  uniform  database  management  and  access.  Because  of  the 
required  data  conversion  some  information  may  have  been  lost.  Implementation  of  the 
simulation  method  was  discussed  earlier  with  the  forward  and  back  annotations  is  also  not 
easy.  Because  of  these  reasons,  interfacing  as  an  extension  method  is  recommended  in  the 
case  of  small  applications  that  realise  a  small  number  of  design  steps  and  where  these 
constraints  do  not  cause  flexibility  loss. 

The  real  integration  of  a  CAD  tool  does  not  have  these  disadvantages  but  requires  much 
more  programming  effort  from  the  CAD  engineers  because  of  the  complexity  of  the 
commercial  framework  products. 


3.1  High-Level  Synthesis  Tool  Integration  to  the  Design  Framework  II 

One  of  the  most  popular  frameworks  is  the  Design  Framework  II®[18]  of  the 
Cadence  OPUS  that  is  extensible  with  C  or  SKILL[19]  programming  languages.  A  new 
high-level  synthesis  tool  has  been  developed  and  integrated  into  this  framework.  This 
program  provides  a  user-friendly  environment  for  editing,  simulating  and  synthetising  the 
data-flow  graph,  as  illustrated  in  Fig.  1.  The  synthesis  procedures  cover  the  algorithms 
discussed  in  this  paper.  The  created  data-flow  graph  may  be  a  part  of  a  larger  design,  its 
inputs  and  outputs  may  be  connected  to  other  schematics  and  FIDL  descriptions. 


Fig.  1.  Data-flow  graph  editor 


The  design  flow  of  high-level  synthesis  is  shown  in  Fig.  2.  The  synthesis  procedure 
starts  with  the  data-flow  graph  that  may  be  entered  by  using  the  graphics  editor  or 
may  be  derived  from  a  VHDL  description  via  a  VHDL  to  DFG  compiler.  This  VHDL 
interface  may  be  useful  because  the  well-known  benchmarks  are  written  in  VHDL. 
The  graph  is  stored  on  the  disks  in  the  standard  CDBA  format  (Cadence  Database) 
and  a  completely  new  view  type  is  associated  with  it  {dfg).  The  view  of  the  VHDL 
description  is  derived  from  the  vhdl  view  type.  This  description  may  be  simulated  by 
the  Leapfrog®  simulator.  The  nodes  of  the  data-flow  graph  are  described  in  three 
different  views.  The  node  view  contains  the  symbol  and  I/O  information  and  is 
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derived  from  symbol  view  type.  The  functional  view  describes  the  behaviour  of  the 
operation  and  it  is  written  in  Verilog  language. [20] 


VHDL  description 


Data-flow  Graph  HLS  constraints 


(l.«apfrogVHi:^ 


^  dfg  >- 


VHDL  to 
DFG 


I 


-(RTIev^A 


Module  Generator 

! 

Test  point 
Generator 

Processor 

Generator 


<■  node  :  > 
c,.;iKinctional  ,i> 
^•■{nodepfop  h 


^cdfg^ 


<3  node.c 

c.  node.d  v 


DFG  Editor 


Other  RT  and  gate  level 
descriptions 


Other  schematics 

Cell  Library  (ES2,  AMS,  MSU) 


Layout 

(GIF,  GSDII,  etc.) 

Fig.2.  Design  flow  of  HLS  tool  in  the  Design  Framework  II 
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Finally,  the  nodeprop  view  defines  the  properties  associated  with  the  processor.  This 
information  is  stored  as  a  set  of  SKILL  statements.  The  predefined  operators  are  collected 
in  the  library  DfgLib.  The  user  may  extend  this  library  by  creating  the  listed  views. 

After  defining  the  HLS  constraints  and  selecting  the  type  of  the  scheduling  by  the 
user,  the  synthesis  procedures  may  be  started  in  the  given  order.  If  required,  the  optimiser 
creates  the  optimised  data-flow  graph  with  the  view  dfg.opt.  The  scheduler  and  the  allocator 
can  create  a  cost  per  performance  curve  to  aid  the  designer  in  selecting  the  run 
configuration  with  the  most  optimal  trade-off.  hnmediately  after  the  scheduling  the  data¬ 
flow  graph  may  be  simulated  standalone  or  with  the  other  part  of  the  design  by  the  Verilog- 
XL®  simulator.  As  a  final  step  of  synthesis,  the  module  generator  creates  the  controlled 
data-flow  graph  (with  the  view  of  cdfg)  and  the  Verilog  RT  level  description  of  processors 
and  control  logic.  The  module  generator  provides  additional  constraints  for  RTL 
synthesiser,  based  on  the  original  user  parameters  and  the  internal  structure  of  the  data-flow 
graph.  The  next  design  step  is  the  technology  mapping  for  the  available  teclmologies  (gate 
arrays,  VLSI,  MCM).  Using  the  final  verification  tools  the  exact  delay  times  may  be 
extracted  from  the  layout  for  simulation  and  back  annotation  purpose. 


4.  Benchmarks 

This  section  contains  four  very  popular  benchmarks  with  their  DFGs,  VHDL 
behavioral  description  and  the  results  that  were  genereted  by  the  PIPE  synthesis  tool.  In  the 
case  of  Differential  Equation  Solver,  the  results  were  produced  in  a  halfautomatic  way 
(PIPE  cannot  handle  recursive  loops  at  this  momement).  The  execution  times  are  used  in 
this  section  (in  clock  cycles): 

t(*)=8  t(+)=4  t(buff.)=l 


4.1  FIR  filter 

The  FIR  filter  is  one  of  the  most  popular  benchmark  that  was  published  in  numerous 
HLS  reports  [6,7,9,12,15]  .  On  this  example  it  can  be  seen  that  how  important  is  the 
definition  of  the  task.  At  this  moment  we  don't  know  a  exact  method  which  could  transform 
an  'optimal'  DFG  from  a  higher  level  description  (equation,  C  function  ...),  since  we  don't 
even  know  what  optimal  means  in  the  case  of  a  DFG.  Comparing  the  structure  a;  and  c;  it  is 
noticeable  that  the  mobilties  in  the  case  of  structure  a;  are  more  than  in  the  case  of  structure 
c;,  while  the  latency  is  less  in  the  structure  c;  (L(c)=5;  L(a)=9).  The  structure  b;  is  a 
recursive  application.  From  chapter  2.5  (equation  2)  it  is  clear  that  there  is  no  worth 
pipelining  in  this  case. 
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The  VHDL  behavioral  description  of  structure  c  is: 

PACKAGE  Global  IS 

TYPE  Vektor  IS  ARRAY  (NATURAL  RANGE  o)  OF  INTEGER; 
FUNCTION  "+"  (L,R  :  Vektor)  RETURN  Vektor; 

END  Global; 

PACKAGE  BODY  Global  IS 

FUNCTION  "+"  (L,R  ;  Vektor)  RETURN  Vektor  is 

VARIABLE  result :  Vektor(L’Range); 

begin 

for  i  in  L'Range  loop 

result(i)  :=  L(i)  +  R(i); 
end  loop; 
return  result; 
end; 

END  Global; 

USE  work.Global.ALL; 

ENTITY  Flr_szuro  IS 

PORT  (  x;  IN  Vektor;  y:  OUT  INTEGER ); 

END  Flr_szuro; 

ARCHITECTURE  vis  OF  Fir_szuro  IS 


SIGNAL 

a,b  :  Vektor(l  TO  8); 

SIGNAL 

c  :  Vektor(l  TO  4); 

SIGNAL 

d  ;  Vektor(I  TO  2); 

CONSTANT 

w:  Vektor(I  TO  8)  :=  (others  =>  I); 

BEGIN 
PROCESS  (x) 

VARIABLE  i,j,k :  INTEGER; 
BEGIN 

FOR  i  IN  I  TO  8  LOOP 

a(i)  <=  x(i-I)  +  x(i)  AFTER  4  ns; 
b(i)  <=  a(i)  *  w(i)  AFTER  8  ns; 
IF  (i  MOD  2)  =  0  THEN 


j  :=  i/2; 

c(j)<=  b(i-l)  +  b(i)  AFTER  4  ns; 
END  IF; 

IF  (i  MOD  4)  =  0  THEN 
k  :=  i/4; 

d(k)<=  c(i/2-l)  +  c(i/2)  AFTER  4  ns; 
END  IF; 

END  LOOP; 

END  PROCESS; 

y<=  d(l)  +  d(2)  AFTER  4  ns; 

END  vis; 


The  PIPE  results: 


1  R: 

7 

9 

11 

13 

15 

30 

a; 

* 

16 

8 

8 

8 

6 

8 

+ 

14 

14 

14 

12 

10 

8 

bu 

83 

52 

52 

40 

29 

0 

c; 

* 

16 

16 

8 

8 

8 

8 

+ 

15 

15 

14 

14 

14 

8 

bu 

44 

22 

16 

0 

0 

0 

4.2  Expansion  of  3*3  Determinant 


The  VHDL  behavioral  description: 


USE  work.Global.ALL; 

ENTITY  graph  IS 

GENERIC  (mt;time:=8  ns;  at:time:=4  ns;  st:tinie:=4  ns); 
PORT(  al  I,al2,al3,a21,a22,a23,a31,a32,a33:in  Real; 
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kimiout  Real); 

END  graph; 

ARCHITECTURE  Viselk  OF  graph  IS 

SIGNAL  ml,  m2  ,m3,  m4,  m5,  m6,  m7,  m8,  m9,  mlO:  Real; 
SIGNAL  mil,  ml2,  al,  a2,  a3,  a4:  Real; 

BEGIN 

ml  <=  al  l*a22  After  mt; 
m2  <=  al2*a23  After  mt; 
m3  <=  al3*a21  After  mt; 
m4  <=  all*a23  After  mt; 
m5  <=  al2*a21  After  mt; 
m6  <=  al3*a22  After  mt; 
m7<=ml*a33  After  mt; 
m8  <=  m2*a31  After  mt; 
m9<=m3*a32  After  mt; 
ml0<=m4*a32  After  mt; 
ml  1<=  m5*a33  After  mt; 
ml2<=m6*a31  After  mt; 

al  <=  m7+m8  After  at; 
a2  <=  mlO+ml  1  After  at; 
a3  <=  al+m9  After  at; 
a4  <=  a2+ml2  After  at; 

kim  <=  a3-a4  After  st; 

END  Viselk; 


R: 

14 

16 

18 

20 

22 

Al 

17 

17 

17 

17 

17 

bu 

68 

68 

56 

56 

56 

4.3  Differential  Equation  Solver 

The  description  of  the  DES  is  a  small  fixed-point  calculation  loop.  The  algorithm 
tries  to  numerically  solve  the  equation: 


y"  +  3xy'  +  3y  =  0 


Here,  u  is  assumed  to  represent  dy/dx  or  y'.  dx  is  approximated  as  xl  -  x.  Similarly,  dy  =  yl 
-  y  and  du  =  ul  -  u.  The  value  'a'  provides  the  number  of  times  the  numerical  loop  is 
executed,  ul,  xl  and  yl  represent  the  new  values  of  u,  x  and  y.  Thus,  xl  =  x  +  dx,  yl  =  udx 
+  y,  ul  =  u  -  3xudx  -  3ydx.  The  behavior  executes  by  loading  the  initial  values  of  x,  y,  u, 
dx,  and  a . 
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The  VHDL  behavioral  description  of  the  DBS; 


USE  work.Global.all; 

entity  diffeq  is 
port  (Xinport:  in  integer; 

Xoutport:  out  integer; 

DXport:  in  integer; 

Aport:  in  integer; 

Yinport:  in  integer; 

Youtport:  out  integer; 

Uinport;  in  integer; 

Uoutport:  out  integer); 
end  diffeq; 

architecture  diffeq  of  diffeq  is 
begin 

PI  :  process  (Aport,  DXport,  Xinport,  Yinport,  Uinport) 

variable  x_var,y_var,u_var,  a  var,  dx  var:  integer  ; 
variable  xl,  yl,  tl,t2,t3,t4,t5,t6;  integer  ; 

begin 

x_var  :=  Xinport;  a  var  :=  Aport;  dx  var  :=  DXport;  y  var  :=  Yinport;  u  var  :=  Uinport 
while  (x_var  <  a_var)  loop 


tl 

=  u 

var  *  dx  var; 

t2 

=  3 

*  x_var; 

t3 

=  3 

*  y_var; 

t4 

=  tl 

*t2; 

t5 

=  dx  var  *  t3; 

t6 

=  u 

var  - 14; 

u_var  :=  t6  - 15; 
yl  :=  u_var  *  dx  var; 
y  var  :=  y  var  +  y  1 ; 
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x_var  :=  x_var  +  dx_var; 


end  loop; 

Xoutport  <=  x  var; 
Youtport  <=  y  var; 
Uoutport  <=  u  var; 

end  process  PI; 

end  diffeq; 


The  PIPE  results  (the  graph  was  tuned  with  opened  loop,  and  the  number  of  the  buffers  in 
the  feedback-path  was  calculated  manualy): 


R: 

7 

9 

11 

13 

15 

30 

AI 

14 

13 

9 

7 

8 

6 

bu 

125 

92 

51 

41 

35 

3 

5.  Summary 

A  HLS  method  and  the  steps  of  a  evaluation  method  were  described.  In  this  paper 
four  popular  benchmarks  was  shown  that  could  be  suitable  to  compare  different  HLS  tools. 
The  DES  can  be  usefull  for  the  application  can  handle  recursions.  The  published  solutions 
were  generated  by  the  PIPE  design  tool.  The  PIPE  can  schedule  and  allocate  structures  wich 
do  not  contain  conditional  branches  ( to  test  this  part  benchmarks  can  be  found  in  [10]  ). 
Another  important  property  of  the  PIPE  is  that  it  can  allocate  just  the  same  type  of 
processors  (the  functions  in  the  behavioral  level  and  the  processors  in  the  RTL  level  are  the 
same).  It  is  also  very  important  to  give  the  exact  definition  of  the  flmctional  element  (timing 
constraints,  if  it  contain  storage  element  or  not,  ...  see  in  Glossary)  to  have  correct 
comparison. 
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Abstract:  Here  we  present  some  algorithms  which  decide,  for  a  given  functional 
specification,  whether  the  function  is  continuous  and  whether  the  function  is  sequen¬ 
tial.  When  the  specification  is  synchronous  (i.e  the  graph  of  the  function  is  realized 
by  a  synchronous  automata)  then  these  two  notions  coincide  with  asynchronous 
sequential  functions  with  bounded  delay.  We  give  an  example  where  Biichi’s  syn¬ 
thesis  by  a  synchronous  sequential  function  is  not  possible,  but  synthesis  by  an 
asynchronous  sequential  function  with  bounded  delay  is  possible.  When  the  speci¬ 
fication  is  asynchronous,  we  present  an  example  of  a  continuous  but  not  sequential 
function,  and  we  give  a  sufficient  criterion  to  prove  that  a  function  is  not  sequential. 

Key-words:  Automata  on  infinite  words,  Synthesis,  Reactive  systems.  Continuity. 

1  Introduction 

Links  between  finite  automata  and  sequential  circuits  are  well  known.  Two  aspects 
are  interesting  in  sequential  circuits:  the  verification  of  a  specification  and  the  syn¬ 
thesis  of  a  specification.  The  importance  given  to  them  was  one  of  the  reasons  which 
motivated  people  to  study  automata  over  a;-words  [8]. 

In  1962  Biichi  proved  the  decidability  of  SIS,  the  monadic  theory  of  one  successor 
[3].  Biichi’s  proof  shows  that  a  SIS  specification  can  be  seen  as  an  automaton  over 
cu-words.  Therefore  the  verification  of  a  SIS  specification  of  a  sequential  circuit 
reduces  to  testing  the  inclusion  between  languages  recognized  by  automata  over 
a;-words,  which  is  a  decidable  property. 

In  the  80’s,  for  non-terminating  reactive  finite  state  programs  this  result  was  ex¬ 
tended  to  several  temporal  logic  system  in  place  of  SIS.  Now  these  verification 
procedures  are  implemented.  For  example,  the  synchronous  programming  language 
Esterel  has  a  module  Tempest  which  verifies  the  temporal  logic  property  of  programs. 
See  [9]  for  an  overview  of  program  verification  (model  checking). 

In  1969  Biichi  and  Landweber,  in  the  context  of  finite  state  games,  showed  that 
the  synthesis  problem  for  a  SIS  specification  is  decidable  [4].  In  the  positive  case, 
the  algorithm  provides  a  deterministic  finite  automaton  which  outputs  letters  and 
realizes  the  specification  given.  There  are  cases  where  the  synthesis  is  not  possi- 
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ble  with  such  an  automaton,  but  is  possible  by  a  deterministic  finite  automaton 
which  outputs  words  instead  of  letters.  This  is  our  starting  point  of  investigation. 
Our  specifications  will  be  graphs  of  functions,  whether  defined  in  SIS  (synchronous 
specification),  or  defined  by  non-deterministic  automata  which  output  words  (asyn¬ 
chronous  specification). 

In  the  synchronous  case  the  synthesis  by  a  finite  state  device  will  be  possible  if  and 
only  if  the  function  is  continuous.  In  this  case,  a  deterministic  automaton  which 
outputs  words  with  bounded  delay  between  the  input  and  the  output  realizes  the 
specification.  We  present  a  combinatorial  test  over  the  graph  of  the  function  which 
decides  the  continuity  of  the  function. 

In  the  asynchronous  case,  we  give  examples  of  continuous  functions  which  can  not 
be  synthetized  by  a  finite  state  device.  We  present  a  combinatorial  test  over  the 
graph  of  the  specification  which  implies  the  non-realizability  by  a  finite  state  device. 
Our  criterion  is  an  extension  to  infinite  word  transducers  of  Choffrut’s  criterion.  We 
do  not  yet  know  if  this  criterion  is  necessary.  The  continuous  functions  given  by 
asynchronous  specifications  are  recursive  functions.  Our  example  of  a  continuous 
function  which  can  not  be  synthetized  by  a  finite  state  device  can  be  implemented 
with  a  stack. 

In  the  second  section,  we  state  some  well-known  definitions  that  we  will  need;  Biichi 
automata,  Muller  automata,  SIS  theory,  transducers  and  Biichi  Landweber  theorem. 
We  need  also  elements  of  topology  because,  in  our  case,  a  function  is  continuous  if 
and  only  if  its  graph  is  closed.  Moreover,  the  natural  classification  of  automata 
over  co-words  is  done  using  topological  methods.  In  the  third  section,  we  study  the 
synchronous  case  and  we  present  our  criterion  for  continuous  functions.  In  the  fourth 
section  we  treat  the  asynchronous  case  and  we  give  our  sufficient  criterion. 


2  Definitions 

We  present  here  some  definitions  we  will  use  later. 

2.1  Infinite  words 

Concerning  the  sets:  V{Q)  denotes  the  power  set  of  a  set  Q.  The  set  of  integers  is 
denoted  by  N. 

Let  W  be  a  finite  alphabet.  An  infinite  word  over  X,  called  a  w-word,  can  be  seen  as 
a  mapping  a  ;  N  ->  X.  So  a  co-word  a  is  a  sequence  a  =  Q;(0)a(l)Q;(2) . . .  a{n) . . . 
where  a{n)  denotes  the  letter  of  a  and  a[n\  denotes  the  finite  left  factor  of  length 
n  of  a.  We  will  define  |u|  to  mean  the  length  of  the  finite  word  u,  so  |Q;[n]|  =  n. 

Over  X,  the  set  of  finite  words  is  denoted  by  X*  and  the  set  of  infinite  words  is 
denoted  by  X‘^.  The  empty  word  is  noted  £. 

We  will  often  employ  examples  concerning  characteristic  functions  of  subsets  of  N. 
A  characteristic  function  of  a  set  can  be  seen  as  an  cu-word,  with  the  least  terms 
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at  the  beginning  of  the  word.  For  example  a  —  10111001000. . .  represents  the  set 
{0,  2,  3, 4,  7},  a  =  0‘^  is  the  emptyset  0  and  a  =  1‘^  is  N  in  its  entirity. 


2.2  Topology 


Let  be  X  a  finite  alphabet.  In  X“  we  will  consider  the  natural  product  topology. 
This  topology  is  also  defined  by  the  distance  d 


cJ :  X  M+  and 

0  if  a  =  P; 


d(a,p) 


X  with  n 


min{/i:/  a[k)  ^  P{k)}. 
With  this  topology  is  a  compact  metric  space. 


We  define  here  the  first  level  of  the  Borel  hierarchy  in  .  We  use  the  logicians 
notation  as  in  Moschovakis’s  book.  The  exponent  equal  to  zero  corresponds  to  the 
first  order  quantifications.  The  suffix  gives  the  number  of  quantifier  alternation.  S 
denotes  the  “3”  quantification.  11  denotes  the  “V”  quantification. 

n?  is  the  class  of  closed  sets; 

'El  is  the  class  of  open  sets; 

n®  is  the  class  of  denumerable  intersections  of  open  sets. 

El  is  the  class  of  denumerable  unions  of  closed  sets; 


Theorem  2.1.  Let  be  X^  and  two  metrisable  compacts,  and  let  be  G  the  graph 
of  the  function  f  :  X‘^  — >•  ,  then 

f  is  continuous  G  is  closed. 


Definition  2.2.  A  function  /  :  X“  — )•  Y^  is  continuous  in  xq  if 
Vn  >  0,  3"^  >  0/  Va;^(a:o[m]  =  x[m])  =»  (f(xo)[n]  =  /(a;)[n])^. 

Theorem  2.3.  The  set  of  the  continuous  points  of  a  function  is  a  IT®  set. 


2.3  Buchi  automata 

Here  we  review  the  Buchi  automata  which  correspond  to  usual  finite  automata 
applied  to  infinite  words. 

Definition  2.4.  A  Biichi  automaton  A  =  (X,  Q,  1, 6,  F)  consists  of  a  finite  alphabet 
X,  a  finite  set  Q  of  states,  a  set  of  initial  states  I  C  Q,  a.  set  of  final  states  F  C  Q 
and  a  next  state  function 

6  :  Q  X  X  ^  V{Q)  and  S{p,  x)  =  {q  e  Q/  q  E  5(p,  rr)}. 

A  Biichi  automaton  A  is  deterministic  if  the  set  of  initial  states  is  reduced  to  only 
one  element  qo  and  if  for  each  letter  and  each  state  there  is  only  one  transition 

f  /  =  {go}; 

I  \/x  E  X,Wp  E  Q,  Card^g  eQJ  q  =  S{p,x)^  =  1. 
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The  run  of  a  Blichi  automaton  A  with  an  w-word  a  -  Q;(0)Q'(l)a;(2) . .  .a{n) . . . 
gives  an  infinite  sequence  of  states  c(a)  =  9o9i92  ■  ■  ■  Qn  ■  ■  ■  with 

f  Qi  ^ 

1  qz+i  e  S{q^,a{i)). 

We  define  the  set  of  states  which  appear  infinitely  often  in  c{a)  by 

Inf (c(q;))  =  {peQ!  Card(z/  Qi  =  p)  =  +oo}. 

Definition  2.5.  Let  a  Buchi  automaton  A  —  {X,  Q,  /,  5,  F).  An  cu-word  a  G  X‘^  is 
accepted  by  A  if  there  is  a  run  c{a)  such  that  Inf  (0(0))  contains  at  least  one  final 
state.  The  cu-language  recognized  by  A,  that  is  the  set  of  tu-words  accepted  by  A,  is 

Loj{A)  {a  G  X^/  3c(a),  Inf(c(Q;))  n  F  0}. 

Example  2.1.  Let  the  Biichi  automaton  A  =  {X,Q,I,5,F)  (fig.l)  where  X  = 
{0, 1},  Q  =  {go,  <?i},  =  {?o},  -f"  =  {90}-  This  automaton  recognizes  the  set  contain¬ 

ing  the  word  a  =  0‘^.  This  word  is  the  characteristic  function  of  the  empty  set  over 
N.  It  is  a  nj  set. 


Example  2.2.  Let  the  Biichi  automaton  A  =  {X,Q,I,S,F)  (fig.2)  where  X  = 
{0,l},<3  =  {9o,9i},^  =  {9o},-^  =  {gi}.  This  automaton  recognizes  the  set  of  words 
which  have  at  least  one  1.  This  set  is  also  the  set  of  characteristic  functions  of 
non-empty  subsets  of  N.  It  is  a  EJ  set. 


Example  2.3.  Let  the  Buchi  automaton  A  =  {X,Q,IA,F)  (fig.3)  where  X  = 
{0A},Q  =  =  {Qo},F  =  {qi}.  This  automaton  recognizes  the  set  of  words 

which  have  a  infinite  number  of  Is.  This  set  is  the  set  of  characteristic  functions  of 
infinite  subsets  of  N.  It  is  a  set. 

Example  2.4.  Let  the  Biichi  automaton  A  =  {X,  Q,  7,  5,  F)  (fig. 4)  where  X  = 
{0,1},Q  =  {90,91,92,93,94},/  =  {9o,92},F  =  {90,93}-  This  automaton  recognizes 
the  set  of  words  which  have  a  finite  number  of  Is.  This  set  is  the  set  of  characteristic 
functions  of  finite  subsets  of  N.  It  is  a  S2  set. 
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Figure  3: 


Definition  2.6.  A  Btichi  automaton  A  =  (A,  Q,  I,  S,  F)  is  unambiguous  if  for  each 
cu-word  a  of  there  is  only  one  sequence  c(a)  which  makes  a  accepted 

Vet  G  L^{A),  Card ^c(q;)/  Inf (0(0;))  n  F  7^  0^  =1. 

Example  2.5.  Let  the  Btichi  automaton  A  =  {X,Q,I,6,  F)  (fi.g.5)  where  X  = 
{0, 1},  Q  -  {^0,  ?i) ?2, ^3}, I  -  {90},  F  =  This  automaton  recognizes  the  words 
beginning  by  0  with  at  least  one  1.  It  is  ambiguous  because  the  words  whose  first 
two  letters  are  01  give  two  different  runs. 


Example  2.6.  Let  the  Btichi  automaton  A  =  {X,Q,I,5,F)  (fig.6)  where  X  = 
{0,1},  <5  =  {9o>  92}) =  {Qq})F  =  {^i}.  This  automaton  recognizes  the  words 

containing  a  finite  non-zero  number  of  Is.  This  is  a  non  deterministic  but  unam¬ 
biguous  Btichi  automaton. 

2.4  Muller  automata 

We  introduce  here  the  Muller  automata. 


Figure  6: 


Definition  2.7.  A  deterministic  Muller  automaton  A  =  (X,Q,qo,S,^)  consists  of 
a  finite  alphabet  X,  a  finite  set  Q  of  states,  an  initial  state  qo  e  Q,  &  set  of  subsets 
of  final  states  T  C  V{Q)  and  a  next  state  function 

S  :  Q  X  X  Q  and 
5{p,x)  =  q. 

By  induction  we  extend  this  transition  function  over  words  of  X*  setting 
5  :  Q  X  X*  Q  and 
f  S{p,e)  =p; 

\  5{p,  ux)  =  S{5{p,  u),  x)  for  u  e  A*,  x  £  X. 

A  deterministic  Muller  automaton  has  only  one  transition  for  each  letter  and  for 
each  state 

Mx  £  X,\/p  £  Q,  Card^g/  5{p,x)  =  q^  -1. 

Definition  2.8.  Let  a  deterministic  Muller  automaton  A  =  {X,Q,qo,S,  An 
cu-word  a  £  X'^  is  accepted  by  A  if  there  is  a  run  c(q;)  such  that  the  set  of  states 
appearing  infinitely  often  is  exactly  one  of  the  sets  describe  in  X .  The  n;-language 
recognized  by  A,  that  is  the  set  of  cu-words  accepted  by  A,  is 

Lu;{A)  =  {a  £  X'^ /  3c(q!),  Inf (c(q;))  e  T}. 

Example  2.7.  Let  a  deterministic  Muller  automaton  A  —  {X,  Q,  go,  A)  (fig.7) 
where  A  =  {0, 1},  Q  =  {go,  A  =  {{go,  gi},  {gi}}-  This  Muller  automaton  recog¬ 
nizes  the  words  with  a  infinite  number  of  Is. 


Figure  7: 


Theorem  2.9.  Let  be  A  C  X'^ .  The  following  conditions  are  equivalent: 

i)  A  is  recognized  by  a  non  deterministic  Biichi  automaton; 
li)  A  is  recognized  by  a  deterministic  Muller  automaton. 
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Remark  2.10.  It  is  easy  to  see  that  the  family  of  sets  recognized  by  deterministic 
Muller  automata  is  a  boolean  algebra.  Also,  the  family  of  sets  recognized  by  non 
deterministic  Biichi  automata  is  closed  under  projection. 

Definition  2.11.  We  call  Auto  the  class  of  sets  recognized  by  automata. 

Lemma  2.12.  If  the  language  recognized  by  an  automaton  A  is  not  empty  then  this 
language  contains  at  least  one  infinitely  periodic  word 

(^L{A)  7^  0^  =4>  ^3a;  G  L{A),3u,v  G  X*,3q  e  Q/  a  =  uv'^,q  e  S{qo,u),q  G 

S{q,v))y 

Lemma  2.13.  The  emptiness  problem  for  automata  is  decidable. 

To  say  whether  a  language  L{A)  is  empty  or  not  is  decidable.  It  suffices  to  test  if 
L{A)  contains  at  least  one  infinitely  periodic-type  w-word.  The  construction  of  one 
successful  word  a  will  be  given  in  finite  time. 

Corollary  2.14.  The  inclusion  problem  between  sets  recognized  by  Biichi  automaton 
is  decidable. 

2.5  Landweber  characterization 

Let  A  =  {X,  Q,  1, 5,  F)  be  a  deterministic  automaton.  One  can  define  other  accep¬ 
tance  conditions.  Let  c  G  be  a  run  of  A. 

c  is  an  accepting  run  if  3i  c(i)  G  F  (Sj  —  condition); 

c  is  an  accepting  run  if  Vi  c(i)  G  F  (11°  —  condition); 

c  is  an  accepting  run  if  3j  Vi  >  j  c(i)  G  F  (E®  —  condition); 

c  is  an  accepting  run  if  Vj  3i  >  j  c{i)  G  F  (H^  —  condition). 

U.i{Auto)  is  the  class  of  sets  recognized  by  deterministic  automata  with  a  llj  — 
condition. 

Tfl{Auto)  is  the  class  of  sets  recognized  by  deterministic  automata  with  a  Sj  — 
condition. 

Ti^^Auto)  is  the  class  of  sets  recognized  by  deterministic  automata  with  a  — 
condition. 

E2(Auto)  is  the  class  of  sets  recognized  by  deterministic  automata  with  a  2°  — 
condition. 

Remark  2.15.  We  have  the  following  inclusions: 

XFfiAuto)  C  n°; 

YTfiAuto)  C  S?; 

Ill{Auto)  C  n°; 

TPfiAuto)  C 

Remark  2.16.  T[\{Auto)  is  the  class  of  sets  recognized  by  deterministic  Biichi  au¬ 
tomata. 
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Theorem  2.17.  (Landweber) 

%)  n°  n  Auto  =  nj  {Aido) ; 
li)  n  Auto  =  YAl{Auto) ; 
in)  112  ^  Auto  —  Il^{Auto); 
iv)  S®  n  Auto  =  EKAuto). 

This  theorem  says  for  example  that  if  a  set  L  is  recognized  by  a  non-deterministic 
Biichi  automaton  and  L  is  a  set  then  we  can  construct  a  deterministic  Bilchi 
automaton  which  recognizes  L. 

Remark  2.18.  Landweber  gives  an  algorithm  to  decide  which  is  the  class  of  a  set 
recognized  by  a  Muller  automaton. 

2.6  SIS  theory 

Biichi  used  sequential  automata  to  prove  decidability  of  the  monadic  second-order 
theory  of  natural  numbers  with  the  successor  relation  which  is  called,  for  short,  the 
second-order  theory  of  one  successor,  or  SIS.  The  variables  of  SIS  range  over  sets  of 
natural  numbers.  SlS  atomic  formulas  have  a  form  A  C  B  or  Succ(A,  B).  The  latter 
means  that  there  is  a  natural  number  n  with  A  —  {n},  B  =  {n  +  1}.  Other  SIS 
formulas  are  built  from  SIS  atomic  formulas  using  conjunction,  disjunction,  negation 
and  the  existential  quantifier.  Every  set  A  of  natural  numbers  can  be  identified  with 
its  characteristic  function,  i.e.  A{n)  =  1  if  n  €  T,  and  A(n)  =  0  otherwise.  For  any 
natural  number  m,  let  Em  be  the  direct  product  of  m  copies  of  the  set  {0, 1}. 

Theorem  2.19.  For  every  SIS  formula  0  with  m  variables  there  is  a  Biichi  Em- 
automaton  A  such  that  for  all  sets  Ai,. . .  ,Am  of  natural  numbers,  4>{Ai, . . .  ,  Am) 
holds  iff  A  accepts  the  Em-sequence 

Ai{0),...  ,Am{0),A^{l),...  ,Am{l),A,{2),...  ,Am{2).  [3] 

The  desired  automaton  A  is  constructed  by  induction  on  f.  The  atomic  case  and 
the  cases  of  conjunction,  disjunction  and  the  existentials  quantifiers  are  easy.  To 
handle  the  negation  it  suffices  to  use  the  equivalence  between  non-deterministic 
Biichi  automata  and  deterministic  Muller  automata  (remark  2.10). 

It  is  easy  to  see  that  sets  recognized  by  automata  are  defined  by  SIS  formulas. 

The  one-element  set  {x}  is  given  by  the  automaton  A  =  {X,  Q,  qo,  S,  F)  (fig.8)  where 
X  =  {0, 1},Q  =  {qoAiA2},F  ^  {qi}. 


The  successor  Succ(a:,y)  meaning  "x  is  the  successor  of  y"  is  given  by  the  au¬ 
tomaton  with  two  input  tapes  A  =  {X,Q,qo,6,  F)  (fig. 9)  where  X  =  {0,1}^,  Q  = 

{qo,quQ2,q3},F  =  {?2}- 


Figure  9; 


The  inclusion  ^  C  B  is  given  by  the  automaton  with  two  input  tapes  A  = 
(X,  Q,  Qo,  S,  F)  (fig.lO)  where  =  {0, 1}^  Q  =  {go,  Qi},F  =  {go}. 


Figure  10: 


2.7  Transducers  and  functions  realized  by  automata 

Definition  2.20.  A  morphism  (p  is  a  function  from  X*  into  Y*  such  that 
=  e  and  (p{uv)  =  <p(u)(p(u). 

It  suffices  to  define  (p  on  letters  of  X.  If  Va  €  X  (p(a)  ^  e  then  we  can  extend  (p  into 
a  function  tp  :  X"-^  — >• 

Definition  2.21.  A  sequential  transducer  T  —  {X,Y,Q,qQ,5,a)  is  a  deterministic 
automaton  with  an  output  function.  It  consists  of  a  finite  input  alphabet  X,  a  finite 
output  alphabet  F,  a  finite  set  of  states  Q,  an  initial  state  go,  a  next  state  function 
5  and  an  output  function  a 

5  :Q  X  X  -^Q,  a  :Q  X  X  -^Y*. 

We  extend  the  next  state  and  the  output  functions  over  words  of  X*  by 

5  :  Q  X  X*  ^  Q  with  5{q,e)  =  e  and  5{q,ux)  =  5{6(q,u),x),u  e  X*,x  G  X; 
a  :  Q  X  X*  ^  Y*  with  cr(g,  e)  =  q  and  cr(g,  ux)  =  a{q,  u)a{6{q,  u),x). 

A  sequential  transducer  defines  a  function  f  :  X*  ^  Y*  with  f{u)  =  a{qo,  u). 

We  call  a  transition  p  q  a  sequence  of  states  ppiP2  ■  ■  ■  PnQ  given  by  the  run  of  a 
word  u  e  X*  from  the  state  p.  A  loop  will  be  a  transition  with  q  =  p  so 

If  there  is  no  loop  p  p  with  an  output  word  equal  to  e,  we  can  extend  /  over 
cn-words  /  :  X‘^  — )■  Y^  with 

9 


f{a)  =  a{qo,  a)  =  lim  {a{qo,  Q;[n])). 

n^oo 

If  there  is  a  loop  with  an  output  word  equal  to  s,  f  will  be  a  partial  function 

/  :  — )•  whose  domain  is  recognized  by  deterministic  Muller  automata. 

Definition  2.22.  A  function  f  :  ^  Y‘^  is  sequential  if  it  is  realized  by  a  se¬ 

quential  transducer. 

Remark  2.23.  Any  morphism  is  a  sequential  function. 

Example  2.8.  Let  /  be  the  multiplication  by  2  of  an  integer  /  :  N  ^  N  and 
f{x)  =  2x.  An  integer  is  defined  as  a  singleton  over  N.  Then  its  characteristic 
function  is  an  w-word  containing  only  one  1.  Let  g  :  {0, 1}^  ->  {0, 1}^  be  a  function 
which  doubles  every  0  before  the  first  1.  If  we  reduce  its  domain  to  the  words 
containing  at  most  one  1  we  obtain  the  multiplication  function  /  in  binary  code  and 
p(0’"10^)  =  This  function  g  is  realized  by  the  sequential  transducer  (fig.ll). 


Figure  11: 


Definition  2.24.  A  1-sequential  transducer  T  is  a  sequential  transducer  with  the 
output  function  reduced  to 

a:QxX  ^Y. 

Remark  2.25.  The  function  g  presented  in  (fig.ll)  can  not  be  realized  by  a  1- 
sequential  transducer.  This  can  be  proved  using  the  pumping  lemma.  An  another 
way  to  see  it  is  that  its  graph  can  not  be  defined  in  SIS  because  if  we  add  the 
function  f{x)  =  2x  to  the  language  of  SIS  the  theory  becomes  undecidable  [23]. 

Definition  2.26.  A  sequential  transducer  has  a  bounded  delay  iff  the  length  differ¬ 
ence  between  the  input  and  the  output  labels  of  every  loop  is  0. 

Example  2.9.  The  sequential  transducer  (fig.  12)  has  a  bounded  delay. 


a/a 

b/b 


Figure  12: 
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Definition  2.27.  A  Btichi  transducer  T  =  {X,Y\Q,  I ,  E,  F)  consists  of  a  finite 
input  alphabet  X,  a  finite  output  alphabet  1',  a  finite  set  of  states  Q,  a  set  of 
initial  states  /  C  Q,  a  set  of  final  states  F  C  Q,  a,  finite  set  of  transitions  E  C 
Q  X  X  xY*  X  Q. 

Remark  2.28.  If  we  forget  the  output  we  have  a  non-deterministic  Btichi  automa¬ 
ton. 

Definition  2.29.  To  normalize  a  Btichi  transducer  consists  in  reducing  the  set  of 
initial  states  to  an  initial  state  50,  retaining  from  the  set  of  states  Q  which  are 
accessible  from  Qq,  retaining  the  states  from  which  an  a>-word  can  be  recognized. 

From  now  on  we  will  consider  only  the  normalized  transducers. 

Definition  2.30.  An  unambiguous  Btichi  transducer  T  is  a  Btichi  transducer  such 
that  for  each  w-word  of  Dom{T)  there  is  only  one  acceptant  calculus. 

Remark  2.31.  With  a  normalized  unambiguous  Btichi  transducer,  Vp,  q  e  Q,Vu  £ 
X*  there  exists  at  most  one  transition  p-^q. 

So  with  the  output  of  any  transition  we  can  define  the  output  function  a  :  Q  x  X  x 
Q  ^  Y*.  If  the  transition  p-^q  exists  then  a(p,  u,  q)  is  equal  to  the  concatenation 
of  each  output  present  in  the  transition.  If  a  transition  p  — ^  q  does  not  exist  we 
have  (t(p,  u,  q)  =  0. 

If  there  exists  no  loop  p-^p  such  that  a{p,u,p)  =  e  then  the  transducer  defines 
a  partial  function  /  :  Dom{T)  — >  Y‘^.  If  o  G  Dom[T)  there  is  a  unique  accepting 
run  c{a)  =  qQqiq2  ■  ■  ■  ■  The  output  of  a,  /(a)  =  o-(go,  a(0),  a(l),  (?2)  •  •  • ,  is 

the  concatenation  of  the  outputs  of  the  transitions.  If  there  exists  a  loop  such  that 
a{p,u,p)  =  e  some  infinite  words  are  transformed  into  finite  words.  To  eliminate 
these  words  we  reduce  the  input  domain  to  another  one  still  recognized  by  Btichi 
automata. 

Example  2.10.  The  Btichi  transducer  of  (fig.  13)  is  unambiguous. 


Definition  2.32.  A  1-unambiguous  Btichi  transducer  T  is  an  unambiguous  Btichi 
with  the  output  function  reduced  to 

<t:QxXxQ->Y. 
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2.8  Biichi  Land  web  er  theorem 

Definition  2.33.  An  infinite  game  with  two  players  I  and  II  consists  of  two  finite 
alphabets  A  and  Y,  a  subset  S  C  {X  x  Y)^.  I  plays  letters  from  A",  II  plays  letters 
from  Y.  Player  I  constructs  an  infinite  word  a.  Player  II  constructs  an  infinite 
word  f3.  Player  II  wins  if  (a,  /5)  G  S. 

A  strategy  for  player  /  is  a  function  f  :  Y*  ^  X.  A  strategy  for  player  //  is  a 
function  g  :  A+  — >■  Y  (A+  =  X*  —  {e}). 

A  strategy  is  winning  for  I  if  V/?(/(/3), /5)  ^  5.  A  strategy  is  winning  for  II  if 
Va(a,  g(a))  e  S. 

Theorem  2.34.  //  5  C  (A  x  is  recognized  by  a  Muller  automaton  then  one 
of  the  players  has  a  winning  strategy  given  by  a  1-sequential  function  (for  I  it  is  a 
Moore  automaton).  There  is  an  algorithm  which  given  S  decides  which  player  has 
a  winning  strategy  and  constructs  for  this  player  a  Tsequential  function  which  is  a 
winning  strategy. 

See  [23]  for  a  proof.  In  particular  if  II  has  a  winning  strategy  then  he  has  a  1- 
sequential  winning  strategy.  The  theorem  solves  the  synthesis  problem  for  SIS 
specification.  It  is  equivalent  to  the  decidability  of  the  emptiness  problem  for  in¬ 
finite  tree  automata,  which  is  used  to  prove  the  decidability  of  S2S,  the  monadic 
theory  of  the  binary  tree  (two  successors).  S2S  is  a  powerful  tool  to  prove  decidabil¬ 
ity  results  and  is  usually  used  in  the  theory  of  concurrence  to  express  properties  of 
programs.  The  satisfiability  problem  for  several  modal  logic  like  computation  tree 
logic  or  branching  time  logic  can  be  translated  into  a  S2S  formula  (see  [2]).  Landwe- 
ber’s  characterizations  and  decidability  results  can  be  proved  easily  by  the  previous 
theorem. 

3  Synchronous  functions 

Proposition  3.1.  (Arnold)  For  each  Muller  automata  we  can  construct  an  unam¬ 
biguous  Biichi  automata  which  recognizes  the  same  language. 

Corollary  3.2.  Let  be  a  function  f  :  X^  Y"^ .  The  following  properties  are 
equivalent: 

i)  f  has  a  graph  defined  in  SIS; 

a)  f  is  realized  by  an  unambiguous  Biichi  1-transducer. 

Remark  3.3.  The  unambiguous  Biichi  1-transducers  realize  the  synchronous  func¬ 
tions. 

Remark  3.4.  For  a  SIS  specification,  to  be  a  function  can  be  expressed  by  a  SIS 
formula  so  it  is  a  decidable  property. 

Proposition  3.5.  Let  be  f  a  function  whose  graph  is  defined  by  a  SIS  formula,  f 
is  continuous  iff  f  is  realized  by  a  sequential  transducer  with  bounded  delay. 
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Remark  3.6.  If  /  is  continuous  its  graph  is  closed  so  it  is  a  n°(ylnto)  and  we  use 
a  determinisation  over  the  input  to  prove  the  result.  This  fact  has  been  mentioned 
by  [23]  and  [14].  In  the  opposite  sens  this  is  a  particular  case  of  a  result  of  Frougny 
and  Sakarovitch  [11]. 

Example  3.1.  A  continuous  function  /  is  defined  by  the  unambiguous  Btichi  1- 
transducer  (fig.  14).  The  sequential  transducer  with  bounded  delay  (fig.  12)  realizes 

/• 


Remark  3.7.  This  function  can  not  be  realized  by  a  1-sequential  transducer.  This 
can  be  proved  using  the  Biichi  Landweber  theorem  on  determination  of  finite  state 
games  -  player  I  has  a  1-sequential  winning  strategy  so  player  II  does  not  have 
a  strategy.  This  is  an  example  where  Btichi  says  there  is  not  synthesis  for  the 
specification.  But  in  fact  we  can  synthesize  the  specification  by  a  sequential  circuit 
which  outputs  words.  We  think  it  will  be  interesting  to  find  real  examples  of  this 
kind  for  applications  in  non-terminating  reactive  finite  state  programs. 

Proposition  3.8.  Let  be  f  a  function  whose  graph  is  defined  by  a  SIS  formula.  The 
set  of  points  of  continuity  of  f  is  a  II®  {Auto) . 

Proof:  It  is  easy  to  see  that  the  set  of  points  of  discontinuity  of  /  is  defined  by  a 
SIS  formula  so  by  theo.  2.19  it  is  in  Auto,  by  theorem  2.17  and  theorem  2.3  it  is 
li^iAuto).  □ 

This  proposition  could  be  used  if  we  are  interested  in  the  synthesis  over  a  given 
domain. 

Theorem  3.9.  Let  be  f  a  function  realized  by  an  unambiguous  Biichi  1-transducer 
T  (fig  15).  f  is  not  a  continuous  function  iff  there  exists  a  pair  of  states  (^1,^2)  o,nd 
a  pair  of  words  {u,  v)  such  that 

i)  the  loop  Qi  — does  not  meet  a  final  state; 
the  loop  q2  — %  92  meets  a  final  state; 

ii)  a{qo,u,qi)  =  Ui; 

a{qo,u,q2)  =  U2;  (1) 

(^iq2,v,q2)  =  V2;  and 
Ui  U2  or  Vi  7^  V2. 
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Proof:  Let  there  be  a  pair  of  states  qi,  q2  and  a  pair  of  words  v  such  that  condition 
(1)  holds.  Let  the  sequence  of  words  be  {uv'^wP).  We  have 

fiuv'^wP')  —  UiVyWitf  and  lim  uv'^wf  —  uv'^, 
lim  =  uivf,  but  fiuv‘^)  =  ^2^2  7^ 

n— >00 

/  can  not  be  continuous  because  the  limit  of  the  image  of  the  sequence  is  not  equal 
to  the  image  of  the  limit  of  the  sequence. 

On  the  opposite  sens  the  proof  uses  the  characterization  of  Landweber  on  Muller 
automata  to  prove  the  assertion.  ^ 

Lemma  3.10.  Let  T  be  an  unambiguous  Biichi  1-transducer  realizing  a  function  f. 
For  a  pair  of  states  (gi,g2),  if  there  exists  a  pair  of  words  (u,n)  such  that  (1)  holds 
then  there  exists  a  pair  {u,v)  with  |'ur’|<  such  that  (1)  holds. 

Corollary  3.11.  Let  f  be  a  function  realized  by  an  unambiguous  Biichi  1- 
transducer.  It  is  decidable  whether  f  is  not  continuous. 

Remark  3.12.  We  have  noted  that  for  SIS  specification  to  be  a  closed  set  is  de¬ 
cidable  (remark  2.18),  and  for  SIS  functional  specification  to  be  continuous  can 
be  expressed  by  a  SIS  formula.  This  gives  two  other  ways  to  prove  the  corollary. 
But  we  prefer  a  combinatorial  criterion  which  is  visual.  Our  algorithm  to  prove 
non-continuity  has  a  A^F-complexity. 


4  Asynchronous  functions 


If  there  exists  no  transition  p-^qwe  denote  the  output  by  a{p,  u,  q)  =  0. 


Definition  4.1.  Let  be  T  =  {X,Y,Q,qo,  E,  F)  an  unambiguous  Biichi  transducer. 
Two  states  qi,q2  G  Q  (fig.l6)  are  twinned  iff  Vn,  u  G  X*  the  following  condition 
holds 


a{qo,u,qi)  =  ui  ^  0 

(^{qo,u,q2)  =U2^0 
(^{qi,v,qi)  =vij^0 
V,  q2)  =V2j^0 


=4>  MiUiUi  ^  =  U2V2U2 


(2) 
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Figure  16: 

Definition  4.2.  Let  T  —  {X,Y,Q,qo,  E,  F)  be  an  unambiguous  Biichi  transducer. 
T  has  the  twinning  property  if  any  two  states  are  twinned. 

Remark  4.3.  This  property  of  transducers  has  been  used  to  characterize  the  sub- 
sequential  functions  as  a  class  of  rational  functions  over  finite  words  [7],  [2]. 

Proposition  4.4.  Let  U1U2V1V2  E  Y*  [7].  Then 

UiViUi^  =  ^2^2%^ 

iff  one  the  following  conditions  is  verified 
i)  vi=^V2=  e; 

ii)  vi  V2,  and  there  exists  e  EY*  such  that  either 

a. a)  U2  =  UiC  and  ev2  =  Uie; 
ii.b)  Ui  =  U2e  and  evi  =  V2e. 

Lemma  4.5.  Let  be  T  an  unambiguous  Biichi  transducer.  For  a  pair  of  states 
(?i»?2)  ff  there  exists  a  pair  of  words  {u,v)  such  that  (2)  does  not  hold  then  there 
exists  a  pair  {u,v)  with  \uv\<  2n^  such  that  (2)  does  not  hold  [7]. 

Corollary  4.6.  Let  be  T  an  unambiguous  Biichi  transducer.  It  is  decidable  whether 
or  not  T  has  the  twinning  property  [7] . 

Example  4.1.  The  unambiguous  Buchi  transducer  T  (fig.  17)  which  realizes  the 
function  /  :  X‘^  — >■  X‘^  has  the  twinning  property 

f{oF)  =  a{caY  =  {acff] 
f  {a^~^^bX‘^)  —  a{caffbX'^,  n  >  0; 

<  f  {a'^'^^cX‘^)  —  {acff~^^cX‘^ ,  n  >  0; 

fibX‘^)  =  bX^-, 

^  f{cX-)  -  cX-  . 

Theorem  4.7.  Let  be  f  a  sequential  function.  For  each  unambiguous  Biichi  trans¬ 
ducer  T  realizing  f ,  T  has  the  twinning  property. 

Example  4.2.  Let  be  a  function  /  :  X"  Y'^  realized  by  the  unambiguous  Biichi 
transducer  T  (fig.  18).  /  is  continuous  but  /  is  not  sequential. 

{  =  (oa)""  = 

I  f{oFbX^)  =  a^^bX^,  n  >  0; 

[  f  loFcX^^)  =  a^cX^^,  n  >  0  . 
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This  function  /  is  continuous.  Let  be  the  alphabets  A  -  {a,b,c,x,y,z,t}, 
B  =  {a,b,c},  C  =  {a,b,c,aa}.  Let  us  consider  the  set  K  C  recognized  by 
the  automaton  (fig.  19).  Let  G  be  the  graph  defined  by  the  unambiguous  Btlchi 


Figure  19: 

transducer  T.  IT  is  a  I[\{Auto)  so  it  is  a  compact  set.  Let  us  consider  the  following 
bimorphism  ((/?,  ip)  defined  by: 
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<F(a)  =  a; 

II 

go{b)  =  b] 

ip{b)  =  b] 

ip{c)  =  c; 

ip{c)  ^  c; 

(p(x)  =  a; 

ip{x)  =  aa 

g>{y)  =  a; 

ip{y)  =  a; 

ip{z)  =  a; 

ip{z)  =  aa\ 

cf 

II 

ip{t)  =  a. 

We  have  {ip,ijj){K)  =  G{f).  (if,  ip)  is  continuous  so  {(p^‘ip){K)  is  compact  and  /  is 
continuous  since  G{f)  is  closed. 

However  /  is  not  a  sequential  function  because  T  does  not  have  the  twinning  prop¬ 
erty: 

Ui—aa 

Uo  —  Cl  /  ,  _i  x 

^  V2  =  a 

Example  4.3.  The  unambiguous  Biichi  transducer  T  (fig.  17)  has  the  twinning 
property.  The  function  realized  by  T  is  also  realized  by  the  sequential  transducer 

r  (fig.2o). 


Figure  20: 


Proposition  4.8.  Let  there  be  a  function  f  :  X‘^  — >■  realized  by  a  unambiguous 

Biichi  1-transducer 'T .  We  have 

f  is  not  continuous  T  does  not  have  the  twin  property. 

The  continuous  criteria  (1)  and  the  twinning  criteria  (2)  are  similar.  For  synchronous 
functions,  (2)  is  a  necessary  and  sufficient  criteria  to  have  sequentiality.  For  asyn¬ 
chronous  functions  we  would  extend  this  result  to  obtain  the  decidability  of  sequen¬ 
tiality  (for  rational  functions  on  finite  words  this  is  a  decidable  property)  [2]. 

Example  4.4.  The  unambiguous  Biichi  transducer  T  (fig. 21)  realizes  the  following 
function  /: 

.  .  _  f  0^^  if  a  =  0‘^, 

(  1“  if  Q;  contains  at  least  one  1. 

Obviously,  this  function  /  is  not  continuous  and  the  transducer  T  does  not  have  the 
twinning  property. 
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Figure  21: 


5  Conclusion 

Our  continuous  function  example  (fig. 18)  is  a  real  algorithm.  It  can  be  implemented 
with  a  stack.  While  we  see  a  we  write  a  and  store  a  in  a  stack.  When  we  see  c  we 
write  c  and  after  we  just  rewrite  the  input.  But  if  we  see  b  then  while  the  stack  is 
not  empty  we  write  the  top  of  the  stack  and  pop,  then  when  the  stack  is  empty  we 
write  b  and  after  we  just  rewrite  the  input. 

Continuous  functions  defined  by  unambiguous  Biichi  transducer  are  recursive  func¬ 
tions.  There  are  closed  links  with  the  synchronous  decision  diagram  of  Vuillemin 
[24].  As  it  was  remarked  by  Klauss  Winkelmann  our  continuous  function  example 
(fig.18)  is  an  online  function  (Va,/3  d{f{a)J{p))  <  d{a,/3)).  We  hope  our  work 
will  be  used  in  the  context  of  non-terminating  reactive  programs. 

To  finish,  we  note  that  the  example  (fig.18)  proves  that  we  can  not  extend  the 
Biichi  and  Landweber  theorem  on  finite  state  games  (they  said  that  if  a  player  has 
a  strategy  then  he  has  a  1-sequential  strategy)  to  cu-rational  relations  of  [11].  If  we 
take  for  specification  the  graph  of  5*  C  (W  x  Y)^^,  the  player  II  has  a  unique  winning 
strategy  which  is  not  a  sequential  function. 
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Abstract 

This  paper  presents  computer  processing  methods  which  automatically  generate  the 
Markov  matrix  of  a  system  from  logical  expressions,  to  make  easier  the  reliability  and 
availability  evaluations. 

These  methods  can  take  into  account  any  relationships  between  transition  rate  values  and 
configurations  of  the  states  of  the  system  (cold  redundancies,  conditional  maintenance..). 
Moreover,  they  allow  the  dimension  of  the  matrix  to  be  optimised  by  grouping  the 
equivalent  states. 


Resume 

Afin  de  faciliter  les  evaluations  de  fiabilite/disponibilite,  cette  communication  presente 
une  methode  de  generation  automatique  de  la  matrice  de  Markov  d'un  systeme  dont  le 
fonctionnement  est  defini  a  partir  d'expressions  logiques. 

Cette  methode  permet  de  traiter  d'eventuelles  relations  de  dependance  (redondance 
froide,  maintenance  conditionnelle...),  et  limite  la  taille  de  la  matrice  obtenue  en 
regroupant  les  etats  equivalents  du  systeme. 


Introduction 

Markov  processes  can  be  used  to  model  the  behaviour  of  many  systems  and  to  calculate 
reliability/availability  much  more  precisely  than  through  simulations  (Monte-Carlo). 
However,  this  type  of  model  requires  a  complex  construction  for  more  than  around  ten 
states,  and  this  cannot  be  done  manually. 

Moreover,  the  number  of  states  increases  exponentially  with  the  number  of  elements  in 
the  system  (2"  for  n  elements  with  two  states  :  correct  operation  and  failure),  often 
making  calculations  very  difficult  and  limiting  the  size  of  the  systems  studied. 

The  aim  of  this  article  is  to  present  computer  processing  methods  which  automatically 
generate  the  Markov  matrix  of  a  system,  using  logical  expressions  which  characterise  its 
operation,  and  which  allow  the  dimension  of  the  matrix  to  be  optimised  by  grouping 
some  of  the  states  together. 
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1-  Logic  analyser  based  on  the  principle  of  insertion 

The  Markov  matrix  of  a  system  of  n  elements  can  be  constructed  in  a  simple  way  using 
insertion.  The  combinations  of  the  states  "correct  operation"  (a)  and  "failure"  (na)  of  the 
various  elements  (a,  b,  c...)  are  arranged  as  follows; 


1  2  3  4  5  6  7  8 


c 

b 

a 

1 

- 

^a 

Xc 

c 

b 

na 

2 

Pa 

- 

^b 

Xc 

c 

nb 

a 

3 

Pb 

- 

Xa 

Xc 

Xc 

c 

nb 

na 

4 

Pb 

Pa 

- 

nc 

b 

a 

5 

PC 

- 

Xa 

Xb 

Xb 

nc 

b 

na 

6 

PC 

pa 

- 

nc 

nb 

a 

7 

PC 

Pb 

- 

Xa 

nc 

nb 

na 

8 

Pc 

Pb 

Pa 

- 

3  element  matrix 

Coefficients  Xjj  represent  the  transition  rates  from  line  states  i  (left)  to  column  states  j 

r  1 

Transition  rates  Xa  and  pa  are  respectively  the  failure  and  repair  rates  of  element  a. 


The  states  for  which  the  system  is  available  can  be  simply  defined  using  a  logical 
expression  relating  the  various  elements. 

Any  relationships  linking  certain  transition  rate  values  to  configurations  of  the  states  of  the 
system  can  also  be  expressed  in  this  way. 

This  type  of  relationship  is  used  for  example  for  conditional  maintenance  or  for  cold 
redundancies  (A-*  =  L/IO  for  an  element  which  is  switched  off). 

The  approach  is  illustrated  in  the  following  example: 


Available  states ;  (a  and  b)  or  c 
Dependency  relationships  :  a  and  b  Xc* 


MAT 

: 

1 

2 

3 

4 

5 

6 

7 
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c  b  a 

1 

- 

Xa 

Xb 

c  b  na 

2 

Pa 

- 

Xb 

Xc 

c  nb  a 

3 

Pb 

- 

Xa 

Xc 

c  nb  na 

4 

Pb 

Pa 

- 

Xc 

nc  b  a 

5 

Pc 

- 

Xa 

Xb 

nc  b  na 

6 

Pc 

Pa 

- 

Xb 

nc  nb  a 

7 

Pc 

Pb 

- 

Xa 

nc  nb  na 

8 

Pc 

Pb 

Pa 

- 

1 

1 

1 

1 

o 

o 

o 

This  method  for  automatically  generating  the  Markov  matrix  is  currently  included  in  the 
Supercab'  software,  which  is  used  at  CNES  for  some  assessments. 

The  states  for  which  the  system  is  available  are  defined  by  a  logical  expression  of  the  form 
n(axb+n(c+exnf))  using  the  logical  operators  OR  (+),  AND  (x),  and  NOT  (n),  where  letters 
a,  b,  c,  e,  and  f  represent  the  elements  of  the  system. 

Dependency  relationships  can  be  written  using  similar  expressions. 


‘  Produced  by  Microcab,  1 13  rue  du  Chateau  Paris  75014,  France. 
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The  software  tool  uses  insertion  to  construct  the  system  matrix.  Dependent  links  are  taken 
into  account  by  modifying  the  transition  rate  values  using  the  corresponding  logical 
expressions. 

The  user  need  not  built  the  matrix  itself,  which  means  that  it  is  relatively  easy  to  determine 
the  availability  of  a  complex  system.  This  is  illustrated  in  the  following  example: 


Loss  of  C  or  D  ->  use  A 
Loss  of  E  or  (D  and  A)  ->  use  B 


Logical  expressions 


Available  states 

hr-' 


cxdxe+axe+cxb 


Xa 

7,00E-O5 

X.a* 

7,00E-06 

cxd 

ga 

9,00E-03 

Xb 

8,00E-05 

Xb* 

8,00E-O6 

ex(d+a) 

Hb 

7,00E-03 

Xc 

4,50E-05 

HC 

8,00E-03 

Xd 

7,50E-05 

tid 

6,00E-02 

Xe 

9,00E-04 

_ _ 

9,50E-03 

Availability 


In  spite  of  the  attractiveness  of  this  processing  method,  one  major  disadvantage  is  that  the 
dimension  of  the  matrix  generated  (2")  can  rapidly  restrict  its  use. 

A  method  for  grouping  states  which  minimises  this  problem  is  therefore  presented  below. 


2  -  Grouping  states 

Many  groups  of  states  are  possible  within  a  system  as  long  as  not  all  of  the  elements  are 
considered  to  be  individually  repairable. 

Indeed,  the  configuration  of  the  system  often  results  in  some  states  being  equivalent.  If 
there  are  symmetries  in  the  system  architecture,  the  number  of  equivalent  states  can  be 
significantly  increased. 
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The  following  example  illustrates  how  states  can  be  grouped  together: 


Hypotheses : 

a  and  a'  identical  elements 

b  and  b’  identical  elements 

c  and  c’  identical  resources 

The  number  of  elements  used  simultaneously 
is  minimised 


Losing  resource  c  (power  supply  of  a  and  b)  has  the  same  effect  on  the  system  as  losing 
both  a  and  b. 

Using  equivalences  of  this  type  and  the  set  of  symmetries  which  may  be  observed  in  the 
architecture  allow  the  64  (2  j  states  of  the  system  to  be  grouped  into  6  distinct  states. 

The  reduced  Markov  matrix  then  becomes: 


1 

2 

3 

4 

5 

6 

No  failure  :  1 

- 

Xa+la* 

?.b+X.b* 

0 

XC+XC* 

0 

Loss  of  a  or  a' :  2 

0 

- 

0 

Xb 

Xb*+Xc* 

Xa+Xc 

Loss  of  b  or  b' :  3 

0 

0 

- 

Xa 

Xa*+Xc* 

Xb+Xc 

Loss  of  a  and  b'  or  a'  and  b  ;  4 

0 

0 

0 

- 

0 

?.a+Xb+2Xc 

Loss  of  all  redundancies  :  5 

0 

0 

0 

0 

- 

Xa+Xb+Xc 

Loss  of  the  system  :  6 

0 

0 

0 

0 

0 

0 

Repair  rates  for  entire  blocks  can  then  be  introduced  into  the  reduced  matrix  (e.g.:  repair 
rate  of  block  abc). 

In  many  cases,  this  method  for  grouping  states  prevents  the  number  of  combinations  of 
states  from  becoming  too  large.  However,  it  requires  an  in-depth  and  often  tedious 
analysis  of  how  the  system  operates,  and  can  lead  to  errors  such  as  incorrect  grouping 
(state  4  often  forgotten  in  the  above  example). 

Because  of  this,  a  way  of  making  the  analysis  automatic  was  developed. 


3  -  Automatic  method  for  grouping  states 

A  method  for  grouping  states  was  designed  and  a  model  developed.  First,  both  the 
logical  expressions  defining  the  system's  available  states  and  any  dependency 
relationships,  are  decomposed  into  simple  elements.  Then  the  states  which  result  in 
identical  logical  states  for  each  of  these  simple  elements  are  grouped  together. 
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The  following  example  illustrates  the  approach: 


States 

axb 

c 

Grouped  states 

c  b  a 

1 

1 

^  c  b  a 

c  b  na 

0 

1 

1 

c  nb  a 

0 

1 

1  ->  c  nb  na 

c  nb  na 

0 

1 

1 

nc  b  a 

1 

0 

->  nc  b  a 

nc  b  na 

0 

0 

1 

nc  nb  a 

0 

0 

1  ^  nc  nb  na 

nc  nb  na 

0 

0 

1 

c 

Cold 

Available  states:  axb+c 
Dependency  relationships  :  Xc*  if  axb 


Two  simple  and  distinct  elements  axb  and  c  are  obtained  by  decomposing  the  logical 
expressions.  1  represents  the  state  "correct  operation",  0  represents  "failure". 

For  identification  purposes,  each  group  of  states  takes  the  name  of  the  state  of  the  group 
which  contains  the  most  failed  elements  (c  b  na,  c  nb  a,  c  nb  na  — >■  c  nb  na). 


This  method  of  preliminary  grouping  is  very  effective  for  many  real  situations. 
The  examples  analysed  above  give  the  following  results: 


cxdxe+axe+cxb 
cxd  => 

cx(a+d)  =>  Xb* 


Grouped  states 

1 

2 

3 

4 

5 

6 

7 

8 

a  b  c  d  e:  1 

- 

Xa* 

Xb* 

Xd 

na  b  c  d  e  2 

- 

Xb* 

Xd+Xe 

Xc 

a  nb  c  d  e;  3 

- 

Xa* 

Xd+Xc 

Xe 

a  b  c  nd  e:  4 

- 

Xb*+Xc 

Xa+Xe 

na  nb  c  d  e:  5 

-  ' 

Xc+Xd+Xe 

a  nb  nc  nd  e:  6 

- 

Xa+Xe 

na  b  c  nd  ne;  7 

- 

Xb+Xc 

na  nb  nc  nd  ne:  8 

- 

The  dimension  of  the  resulting  matrix  is  8  instead  of  32  (2^). 
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axbxc+dxfxbxc+axcxexf+dxexf 


axbxc  =>  X,d*  nbxdxexf  =>  A,a* 
axbxc  naxdxexf  =>  A,b* 

axbxc  =>  Xf* 

naxdxexf+nbxdxexf  Xc* 


Grouped  states  1  2  3  4  5  6  7 


a  b  c  d  e  f 

1 

/.a  Xb  Xd*  Xe* 

Xc 

Xt* 

na  b  c  d  e  f 

2 

Xe 

Xb*+Xc* 

Xd+Xf 

a  nb  c  d  e  f 

3 

- 

Xd 

Xa*+Xc* 

Xe+Xf 

a  b  c  nd  e  f 

4 

- 

Xb 

Xe*+Xf* 

Xa+Xc 

a  b  c  dne  f 

5 

Xa 

Xd*+Xf* 

Xb+Xc 

na  b  c  dne  f 

6 

- 

Xb+Xc+Xd+Xf 

a  nb  c  nd  e  f 

7 

- 

Xa+Xc+Xe+Xf 

na  nb  nc  d  e  f 

8 

- 

Xd+Xe+Xf 

a  b  c  nd  ne  nf 

9 

- 

Xa+Xb+Xc 

na  nb  nc  nd  ne  nf 

10 

- 

The  dimension  of  the  resulting  matrix  is  10  instead  of  64  (2^). 


Conclusion 

Assessing  reliability/availability  can  enable  both  the  system  architecture  (redundancies, 
cross-strapping,  reconfiguration  procedure,  etc.)  and  maintenance  policies  (spare  parts 
batch,  preventive  maintenance,  availability  of  technical  staff,  etc.)  to  be  optimised. 

As  a  result,  the  global  cost  of  a  product  can  often  be  significantly  reduced.  However  this 
assessment  is  sometimes  difficult  to  carry  out,  particularly  for  non-specialist  designers. 

The  work  described  here  helps  solve  this  problem  by  providing  users  with  tools  which 
only  require  knowledge  of  the  logical  operation  of  the  system  concerned. 

Moreover,  the  suggested  method  for  grouping  states  should  allow  Markov  techniques  to 
be  extended  to  complex  systems  with  many  interdependent  elements. 

Further  research  could  improve  this  method  in  order  to  identify  and  exploit  symmetries  in 
the  architecture.  Indeed,  for  most  applications,  the  system  contains  identical  elements 
which  can  lead  to  further  grouping  of  states. 
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Abstract 

With  diminishing  budgets  of  space  agencies  around  the  World,  it  becomes  critical  to  search 
for  lower  cost  solutions  to  keep  exploration  programs  alive.  One  of  the  cost  contributing 
factors  is  the  common  use  of  rad-hard  electronic  devices  for  space  applications.  This  paper 
questions  this  requirement  by  proposing  an  alternative  which  employs  highly  adaptable 
microelectronic  architecture  potentially  absorbing  the  impact  of  space  bom  defects.  The 
FPGA  soft  programmable  device  under  study  is  driven  by  a  rad  hard  80186  microprocessor. 
The  proposed  experiment,  called  TRIAD,  enables  the  validation  of  different  fault  models  in 
space  borne  systems,  with  the  expectation  of  behavioral  fault  models  being  most  attractive. 

Keywords  :  Space  Applications,  VHDL  Modules,  Fault  Tolerance  Devices,  Reconfigurable 
Architecture. 

1  Introduction 

Emerging  paradigms  of  Reconfigurable  Systems  [1],  [2]  which  include  RAMs,  FPGAs  [3], 
PCMCIA  cards,  and  hard  disks  (well  established  technologies)  on  one  hand  and 
Microarchitectures  (an  emerging  low  end  category  of  microelectronic  systems)  on  the  other, 
require  addressing  the  dependability  issue  in  a  novel,  coherent,  and  integrated  fashion.  The 
testing  issue  addressed  in  this  paper  is  considered  in  the  context  of  applying  reconfigurable 
systems  in  space  which  poses  two  additional  challenges: 

•  The  first  one  is  the  problem  of  determining  fault  models  in  space-borne  systems. 
Today’s  radiation-hardened  solutions,  typically  used  in  space  applications,  lag  far  behind 
the  capabilities  of  mainstream  microelectronic  systems  [4].  Shrinking  federal  budgets 
may  further  widen  this  gap,  and  even  eliminate  the  rad-hard  market.  To  expand  the 
number  of  options  for  space-bome  applications,  this  paper  introduces  a  concept  enabling 
semiconductor  engineers  to  study  rad-hardness  alternatives  using  an  approach  based  on  a 
TRIAD;  highly  dependable  systems,  evolving  technologies,  and  advanced  packaging. 
The  focus  is  on  Behavioral  Faults  [5],  [6]  used  as  metrics  to  characterize  the 
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technology-dependability  impact.  Better  understanding  of  physical  defects  manifested  at 
a  lower  than  the  system  level  may  ease  the  need  for  radiation  hard  solution  in  space  by 
employing  massive  redundant  options  in  reconfigurable  systems. 

•  The  second  issue  is  connected  with  the  development  of  small,  light,  and  even 
nanosatellite  technologies  [7]  in  both  scientific  and  commercial  missions.  Rad  hard 
technology  is  generally  expensive,  but  especially  unacceptable  in  a  COTS  oriented  small 
satellite  technology.  Rad  hard  approach  is  by  definition  counterproductive  since  it  uses 
“frozen”  architectural  and  systems  developments.  In  addition,  radiation  effects  are 
typically  considered  at  the  system  level  (e.g.  the  maximal  radiation  dosage  is 
proportional  to  the  Mean  Time  To  Failure  (MTTF)  which  implies  a  system  level 
reliability  model  [8].  This  model  does  not  take  into  account  the  logical  and  frinctional 
structure  of  a  microelectronic  device).  Thus,  new  models  at  a  lower  level  of  abstraction 
need  to  be  derived. 

The  TRIAD  experiment  can  be  conducted  either  on  Earth  or  in  Space,  or  both,  with  the 
following  trade-offs  in  mind: 

•  An  Earth  experiment  is  very  expensive  with  a  single  test  typically  free  of  charge.  In 
Space  the  cost  can  be  very  reasonable  since  it  is  sufficient  to  conduct  TRIAD  as  a 
secondary  space  experiment  with  a  low  priority  communication  requirements 

•  Artificial  radiation  environment  created  in  a  laboratory  may  not  be  sufficiently  accurate 
to  conduct  this  experiment 

In  the  next  section,  we  present  the  TRIAD  architecture  and  the  scenario  of  Fault  Model 
Validation.  In  the  section  three,  VHDL  description  of  devices  under  test  (a  non-redundant 
register  and  a  triple  redundant  register  with  voter). 

2  The  TRIAD  architecture 

The  TRIAD  architecture  is  a  test  bed  for  conducting  trade-off  studies  between 
technologies,  fault-tolerance,  and  testing  in  space: 

.  Architecture:  Figure  1  represents  a  block-level  diagram  of  the  architecture  system 
concept.  The  upper  part  of  the  design,  an  FPGA-based  bus  interface  and  80186-based  rad- 
hard  controller,  is  implemented  in  technologies  with  high  survivability  in  space.  The  lower 
part  corresponds  to  the  Unit  Under  Test  (UUT),  with  uncertain  space  survivability.  UUT 
represents  a  volume  in  three  dimensional  space  determined  by  testability,  technology,  and 
fault  tolerance  selected  for  the  experiment. 

.  Dynamically  Reconfigurable  UUT'.  An  attractive  solution  for  UUT  appears  is  a 
dynamically  reconfigurable  architecture  [1],  [2].  In  this  case,  a  system  using  preprogrammed 
information  about  its  desired  configuration  respond  to  outside  environment  by  generating 
the  “best”  architecture.  A  good  example  is  a  soft-reconfigurable  FPGA  arrangement  when  a 
silicon  device  can  change  its  configuration  [9].  A  merge  of  the  concept  and  technology  has 
lead  to  “reconfigurable  computing”  [10]  as  well  as  to  “morphological”  systems  [11].  Test 
and  diagnosis  in  FPGAs  using  this  approach  is  described  in  [12]  where  physical  defects  are 
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diagnosed  through  a  variety  of  logical  architectures  reconfigured  for  easy  testing.  We  are 
proposing  a  similar,  but  modified  approach  since  neither  the  adequate  architecture  nor  the 
optimal  fault  model  suitable  for  space  borne  system  is  determined  so  far.  Thus, 
reconfiguration  enables  us  to  use  a  microelectronic  system  which  gradually  achieves  desired 
optimum  through  its  flexible  architecture. 


AMERICAN  MODULE  FRENCH  MODULE 


Fieure  1.  The  TRIAD  Concept 

.  The  Scenario  of  Fault  Model  Validation:  The  flow  diagram  for  the  TRIAD  experiment  is 
depicted  concisely  in  Figure  2.  Each  level  of  consideration  reflects  the  flexibility  and 
expandability  of  the  approach.  For  example,  the  technology  level  assumes  a  repetitive 
TRIAD  experiment  for  a  variety  of  technologies.  There  is  at  least  a  pair  of  identical 
microprocessor  based  systems:  one  aboard  the  satellite  (the  SPACE  copy)  and  another  on 
Earth  (the  EARTH  copy).  Only  the  EARTH  version  is  equipped  with  a  simulation/synthesis 
CAD  package.  For  a  given  technology  and  a  given  level  of  abstraction  the  corresponding 
fault  model  and  the  logical  architecture  described  in  VHDL  is  considered.  The  VHDL  model 
is  synthesized  and  the  target  physical  configuration  is  uplinked  to  the  satellite.  As  a  result, 
both  systems  are  reconfigured  the  same  way,  followed  by  simultaneous  testing  of  both 
copies  with  the  EARTH  copy  treated  as  a  golden  unit.  The  discrepancy  in  the  system 
recognitions  leads  to  fault  detection  followed  by  a  diagnosis  phase.  A  non-empty  fault  map 
employs  a  reconfiguration  scheme  accomplished  again  by  the  two  versions  with  a  proper 
synthesis  and  upload.  The  procedure  is  repeated  until  a  reconfiguration  scheme  absorbs  the 
effect  of  a  fault  resulting  in  the  validation  of  the  fault  model.  Exceptions,  i.e.  when 
absorption  is  impossible,  are  handled  either  by  a  different  reconfiguration  or  a  different  fault 
model  [13]. 
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.  Logical  versus  Physical  Approach.  Two  approaches  are  considered;  the  logical  approach 

when  a  physical  location  of  logic  under  study  is 
not  relevant  and  the  physical  approach  in  an 
opposite  case.  After  detecting  a  defect,  the 
logical  approach  gradually  increases  the 
granulity  of  logic  until  the  effect  of  defect  is 
masked  off  resulting  in  the  fault  model 
validation.  Multiple  and  single  defects  are 
handled  likewise.  After  diagnosing  a  defect,  the 
physical  approach  eliminates  a  block  which 
.the  contains  the  defect  and  resynthesizes  the 
SUP  structure.  Multiple  defects  may  be  difficult  to 
ON  handle  in  the  physical  approach.  However,  this 
approach  suggests  a  new  diagnostic  method  of 
“roving  diagnosis”  which  seeks  for 
malfunctioning  blocks  one  at  a  time.  A  question 
can  be  raised  whether  elimination  of  or  at  least 
reduced  diagnosis  is  feasible  by  using  “reverse 
engineering”  [14]  or  signature  based 
FAULT  MODEL  information.  For  example,  XILINX  FPGA  have 

some  readback  capabilities  useful  in  this  case. 
Additional  Assumptions:  The  initial  architecture 
Figure  2,  The  TRIAD  Experiment  is  assumed  to  have  structure  VI  (developed  on 

Earth  and  uplinked  after  synthesis  to  a  satellite) 
which  results  in  physical  structure  PI.  The  assumed  fault  model  is  based  on  [6]  and  testing  is 
performed  at  the  VHDL  level  (test  vectors  and  test  procedures  are  also  developed  on  Earth 
and  uplinked  to  the  satellite)  followed  by  testing  in  space.  Both  detection  and  diagnosis  is 
performed  at  the  VHDL  level.  Reconfiguration  forced  by  malfunction  is  again  performed  on 
Earth  and  the  results  of  synthesis  (VHDL  model  V2  and  physical  structure  P2  respectively) 
are  uplinked  and  the  process  is  repeated.  Note,  that  it  is  assumed  that  V2  >  VI  (meaning 
that  a  new  fault  tolerant  configuration  may  absorb  the  effect  of  a  fault  detected  in  VI)  as 
well  as  that  P2  >  PI  (a  new  more  powerful  configuration  should  result  in  a  more  robust, 
area  demanding  physical  structure  which  eliminate  the  effect  of  a  failure  present  in  PI).  It  is 
envisioned  that  VI  structure  contains  a  number  of  basic  modules  in  VHDL  which  will 
“cover”  the  whole  silicon  area  provided  by  a  FPGA  chip.  It  is  also  envisioned  that  V2 
structure  generates  the  maximum  capacity  physical  implementation  of  modules  after 
synthesis  which  a  FPGA  device  can  accommodate. 
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3  Implementation  Examples 


It  is  assumed  that  a  microprocessor  based  system  is  based  on  the  Intel  80186  rad-hard 
device  with  a  configuration  analogous  in  one  being  developed  for  the  CATSAT  project. 
UUT  are  soft  programmable  FPGA  devices  programmed  using  logic  synthesis  approach. 
The  two  VHDL  modules  (non-redundant  and  TMR  based)  of  the  device  under  study  are  as 
follows: 


-  Filename  :  example l.vhd 

-  Title  :  Register_ex 
~  Library  ;  synth 

-  Purpose  :  Behavior  description  of  a  register_ex  which  is  used  for  a 

-  reconfigurable  system  concept  devoted  for  space  applications 

-  10 

-  PORT  <name>  <mode>  <type>  <purpose> 


DI 

:  IN  vlbit_ld(l  TO  8) ;  data  in 

STRB 

:  IN  vlbit ;  transfer!  control 

„ 

DSl 

:  IN  vlbit ;  enable  control 

_  _ 

NDS2 

:  IN  vlbit ;  enable  control 

.. 

DO 

:  OUT  vlvlbit_ld(l  TO  8)  data  out 

Entity  register_ex  IS 

PORT  (DI  :  IN  vlbit_ld(l  TO  8)  ; 

STRB,  DS 1 ,  NDS2  :  IN  vlbit ; 

DO  :  OUT  vlbit_ld(l  TO  8) 

); 

END  register_ex; 

ARCHITECTURE  behavior  OF  register  ex  IS 
SIGNAL  reg  :  vlbit_l  d(  1  TO  8); 
SIGNAL  enbld  :  vlbit ; 

BEGIN  -  behavior 
strobe:  PROCESS  (STRB) 

BEGIN  ~  strobe 
IF  (STRB=T')  THEN 
reg  <=  DI ; 

END  IF; 

END  PROCESS  strobe; 
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enable:  PROCESS  (DS1,NDS2) 

BEGIN  -  enable 
enbld  <-  DSl  AND  NOT(NDS2) ; 
END  PROCESS  enable; 

output:  PROCESS  (reg, enbld) 

BEGIN  —  output 
IF  (enbld='l')  THEN 
DO  <=  reg ; 

ELSE 

DO<=X"H''; 

END  IF; 

END  PROCESS  output; 

END  behavior;  —  of  register_ex 

Figure  3.  The  FPGA  Device  Behavior 


—  File  name  :  triple.vhdl 
~  Title  :  triple  redundant  register  with  voter 
~  Library  :  synth 

--  Purpose  :  example  for  reconfigurable  FPGA  for  space  application 


-  10 


PORT  <name> 
DI 

STRB 

DSl 

NDS2 

DO 


<mode>  <type>  <purpose> 

;  IN  vlbit_ld(l  TO  8) ;  data  in 
:  IN  vlbit ;  transfer!  control 

:  IN  vlbit ;  enable  control 
:  IN  vlbit ;  enable  control 

:  OUT  vlvlbit_ld(l  TO  8)  data  out 
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ENTITY  triple  IS 
PORT( 

DI  :  IN  vlbit_  ld(l  TO  8)  ; 

STRB,  DSl,  NDS2  :  IN  vlbit ; 

DO  ;  OUT  vlbit_ld(I  TO  8) 

); 

END  triple; 

ARCHITECTURE  behv  OF  triple  IS 
COMPONENT  register_ex 
PORT( 

DI  ;  IN  vlbit_Id(I  TO  8)  ; 

STRB,  DSl,  NDS2  ;  IN  vlbit; 

DO  :  OUT  vlbit_ld(l  TO  8) 

); 

END  COMPONENT; 

COMPONENT  voter 


PORT( 

DOl 

;  IN  vlbit_ld(l  TO  8) ; 

D02 

:  IN  vlbit  ld(l  TO  8) ; 

DOS 

:  IN  vlbit  ld(lT0  8); 

DO 

:  OUT  vlbit  ld(l  TO  8) 

); 

END  COMPONENT; 


—  signal  declaration 


SIGNAL  DO  1 
SIGNAL  D02 
SIGNAL  D03 


vlbit_Id(I  TO  8); 
vlbit_Id(I  TO  8); 
vlbit_Id(I  TO  8); 


BEGIN-  behv 
cl 00:  register_ex 


PORT  MAP  ( 

DI  =>  DI, 
STRB  =>  STRB, 
DSl  =>DS1, 
NDS2  =>  NDS2, 
DO  =>D01 


); 
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c200;  register_ex  PORT  MAP  ( 

DI  ->  DI, 

STRB  =>  STRB, 

DSl  =>DS1, 

NDS2  =>  NDS2, 

DO  =>  D02 

); 

c300:  register_ex  PORT  MAP  ( 

DI  =>  DI, 

STRB  =>  STRB, 

DSl  =>DS1, 

NDS2  =>NDS2, 

DO  =>  D03 

); 

c400:  voter  PORT  MAP  ( 

DOl  =>D01, 

D02  =>  D02, 

D03  =>  D03, 

DO  =>  DO 

); 

END  behv;  —  of  triple 

4  Current  and  future  work 

Our  current  work  deals  with  several  aspects  : 

i  The  design  of  the  devices  under  test  using  logic  synthesis  approach. 

ii  Behavioural  feult  modeling  and  fault  simulation. 

iii  Implementation  of  the  scenario  of  fault  model  validation. 

We  envision  launching  the  TRIAD  experiment  aboard  a  satellite  as  part  of  a  future 

international  micro  satellite  designed  and  built  by  international  teams  of  students. 
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Abstract 

The  motivation  for  Integrated  Modular  Avionics  (IMA)  is  presented. 
The  required  high  availability  and  improved  maintenance  efficiency  dictate 
requirements  on  the  consistency  of  data  used  by  re])licated  software  com¬ 
ponents.  It  is  shown  that  a  reliable  innlticast  facility  is  needed  to  fnlfill  the 
con  si  s  t  G 11  cy  req  n  i  rem e n  t . 

Propagation  of  failnres  should  be  prevented.  .An  additional  consistency 
requirement  states  that  software  conqionents  should  consider  the  same  re¬ 
sources  as  failed  at  the  same  time.  It  is  sliown  how  a  membership  algorithm 
can  satisfy  this  requirement.  The  time  liounds  on  communication  and  fail¬ 
ure  detection  propagation  are  calculated. 

keywords:  distributed  systems,  failure  isolation,  embedded  systems, 
software  archi  tect  n  re 


1  Introduction 

An  avionic  application  is  a  good  cxaniple  of  an  einheclded  system.  Two  parts  can 
be  discerned  the  system  under  control  (the  airplane)  a.ncl  the  controlling  system 
(the  set  of  interconnected  processors  with  software).  The  state  of  the  controlled 
system  is  determined  by  the  state  of  the  controlling  system  and  vice  versa.  These 
systems  are  notoriously  conpilex  to  build  because  the  s,ystem’s  response  not  only 
depends  on  the  invoked  function  and  its  input  parameters  but  also  on  the  con¬ 
trolling  system’s  state  and  its  hist.ory.  It  is  clear  that  rigid  guidelines  are  needed 
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to  design  such  .s\'st(.'iiis  ('.specially  when  th('  lailiiig  ol  llu'  system  has  imj^ortant 
conseciuences  in  linancial  or  social  leims. 

Thi,s  Is  es])eciall\’  tiaie  toi'  Ax'ionics  concerned  with  tlic'  coiiti'ol  ol:  tlic  air])la.ne 
during  its  llight  li'oni  its  point  ('ll  de|)artiir('  until  its  th'sl inal ion.  I'allures  ol  tlie 
controlling  sv'steiu  can  h’ad  (o  loss  ol  inoiu'V,  loss  ol  aircralt  or  |.)arts  ol  it  and  loss 
of  life. 

Dui'ing  the  flight  of  an  aii'cralt,  dillerent  pliases  can  fur  discerned  like:  taxiing, 
takeoff,  la.nding  1,  landing  2,  level  llight,..  During  flight  phase’s,  components 
have  criticality  l(;'\'els  that  descrilx'  llu’  seriousno'ss  ol  the  conseciuences  ol  their 
failure.  A  levx'l  is  associated  with  its  maximal  probability  ol  lailure  during  one 
hour  of  flight.  Five  different  ciiticalily  levels  are  discerned  (with  associated  Failure 
probabilit.y):  Ciatastrophic  (10~'’).  Hazardous  (10“'),  Major  (10  "’),  Minor  (10 
and  No  effect(-).  It  is  ck’ar  that  t  he  more  |)robalde  failure  of  a  component  with  a 
low  criticality  level  should  in  no  way  jc'opardize  the  correct  execution  of  the  other 
comjronenl.s.  d'hercloix:',  aA’ionic  syst('ms  were'  constructed  such  tha.t  components 
of  a  given  criticality  level  were  suppoi’ted  by  dedicated  hardware  with  no  electrical 
or  electronic  connections  betwc'en  comi)onents  ol  different  ci'iticality  level. 

The  controlling  system  not  only  needs  to  meet  the  very  demanding  reliability 
and  functional  specifications,  also  t  he  purchasing  and  maintenance  costs  should 
be  as  low  a.s  possible.  An  important,  contiibution  to  the  maintenance  costs  is 
caused  by  the  largn  number  ol  type's  ol  equipment.  A  large  and  e.xpensive  stock 
of  any  type  of  eciuipment.  must,  be  pro\'ided  l)y  an  aircra.lt  operator  to  keep  the 
number  of  flight  deia.ys  within  acceptable  limits. 

The  driving  loi'ce  Ix'hind  the'  introduction  ol  Integrated  Modular  Avionics 
(IMA)  is  (1)  lower  maintenance  cost.  (2)  higher  availability  and  reliability,  and 
(3)  the  need  for  more  soplnst icat('d  and  luel  saving  conti’ol  ol  eejuipment. 

Ad  1)  IMA  provich's  a  set  of  electrical,  electronic,  mechanical  and  software 
standards  in  which  manufacturers  can  |)roduce  a.  standard  set  ol  modules  with 
clilferent  soft.wa.rc  functionalities  that  can  be  used  loi'  a.  wide  range  ol  aircralt 
types  from  dillerent  manufacturers.  The  aim  is  to  provide,  a.  stock  of  standard 
liardwa.re  modules  ^vith  a  reduced  set  ol  types  that  can  be  configured  to  the 
recjuired  functionahtx'.  Such  a  stock  com|.^osed  ol  a.  limited  number  ol  module  types 
leads  to  reduced  maintenance  costs.  Tlie  a].)|dicat.ion  ol  on-board  surveillance  and 
tests  reduces  the  number  of  r('|>lac('ments  ol  correct  ly  tunctioning  modules. 

Ad  2)  IMA  provides  a  set  of  interconnecte’d  jn'oeessors  that  can  be  configured 
to  e.xecnte  a.  number  of  requiiv’d  lunct.ions.  Functions  can  be  replicated  over 
difl'erent  ])rocessors  to  meed,  the  specified  ax’aila.bility  and  reliability  criteria..  The 
number  of  possible  configurations  that  is  larger  lor  IM.A  than  lor  non-IMA  systems 
allows  the  meeting  of  I'elialAility  and  availa.lulity  rec|uirements  with  a  degra.ded 
system  for  lower  costs  than  is  ].)ossil)le  with  the  non-IMA  systems. 

Ad  3)  The  modular  com|)(xsition  ol  au  IM.A  .system  makes  it  amenable  to 
extensions  and  growth.  The  growing  need  lor  computing  ].)ow'er  to  fly  an  aircralt 
with  lower  costs  within  e\'er  smaller  o|.)erational  margins  makes  it  attractive  to 
have  systems  that  ca.n  be  upgrach'd  during  tlie  liletime  ol  the  aircralt  without 


major  motlificat ions  to  all  not  dlroctly  implicated  components.  The  IMA  concept 
provides  sncli  a.  framework. 

The  communication  needs  Ix'twecMi  tin'  I.M.A  modules  and  tlie  possil^ilities  to 
reconfigure  the  IM.A  system  necessitate  the  introduction  of  hardware  and  software 
components  that,  arc  sliared  by  iunctions  ol  diflerent  criticality  level.  This  is  the 
most  importa.nt  difference  from  a  reliability  point  of  view  of  the  IMA  system  with 
respect  to  the  more  traditional  systems.  The  sharing  of  hardware  components  has 
an  impact  on  the  reliabilit.}'  calcnlalion  ol  the  total  controlling  system.  Soltware 
dependencies  should  not  enhance  I  hese  dei^cndcncics  and  care  sliould  be  ta.ken  that 
no  hidden  deiJcndencies  are  introduced,  fhe  prevention  ot  hidden  dependencies 
associated  with  replication  and  a  shared  communication  medium  are  the  subject 
of  this  paper. 

Some  IMA  concepts  and  communication  standards  are  introduced  in  section 

2.  A  software  architecture  that  suppoi'ts  failure  se])aration  is  proposed  in  section 

3.  It  is  sliown  how  the  introduction  of  a  membership  algorithm  [II]  prevents  the 
introduction  of  hidden  dependencies  in  section  4. 

2  Integrated  Modular  Avionics 

In  Fig.  1,  the  shaded  area  re|U'('sent.s  the  conti’olling  s,ystem  (IMA  Host  Sys¬ 
tem).  The  devices,  resources  and  a.e.tuators  arc  part  of  the  controlled  system  (the 
aircraft).  .An  IMA  Host  System  is  composed  of  a  number  of  Remote  Data  Concen¬ 
trators  (RDC)  and  cabinets  interconnected  by  an  airplane  bus  [2].  The  currently 
proposed  airplane  bus  standard  is  ARINC629  [1]  described  in  section  2.1.  A  cab¬ 
inet  houses  Line  Replaceable  Modules  (LRM)  electrically  interconnected  bj^  the 
cabinet  backplane.  The  mecliauical  and  electrical  standard  is  described  in  section 
2.2  according  to  .'\Rr.MC  document  [3].  Sta.nda.rd  LRM’s  are  core  modules  and 
gateway  modules.  Core  modules  contaiji  a.  ])rocessor.  Processors  placed  in  differ¬ 
ent  cabinets  communicate  ovei-  the  airplane  bus  via  the  gateways.  For  reliability 
reasons  gateways  aie  rc|)licat('d.  Pi-ocessors  have  local  clocks  which  are  a.ssumed 
to  be  synchronized.  Imi'  a  jrrocessor  /)  a  dock  function  Cp{t)  is  defined  that  returns 
the  value  of  the  local  clock  at  physical  lime  /.  h'oi’  any  two  correct  processors  p 
and  q  a.nd  given  constant  e,  it  is  assumed  that  |  Cp(t)  —  |<  e.  Assuming  that 

in  short  intervals  clocks  can  lie  approximated  with:  d  Cp{f  )  j dt  ^  1,  the  following 
relation  holds:  Cp(t\)  =  C.^f/j)  =^|  U  —  i-i  \<  f- 

A  core  module  executes  partitions  that  execute  in  isolation  from  other  parti¬ 
tions  on  the  same  core  module.  Private  memory  is  accessible  to  only  one  partition 
and  shared  memory  is  accessible  to  all  partitions  of  a  core  module. 

The  a.i'ionic  application  is  subdivided  in  avionic  functions.  An  avionic  function 
acts  on  the  ec|uipment  of  the  aircraft  based  on  sensor  input  from  the  aircraft 
environment  to  orient  tlie  aircraft  in  space  and  time  in  accoi'dance  with  the  aircraft 
wanted  behaviour.  Fxamples  of  aAuonic  functions  are  yaw-damping,  auto-pilot, 
lift  augmentation  and  others.  .An  avionic  function  is  implemented  with  an  avionic 
system  that  represents  the  hardware  configuration  needed  by  the  avionic  function 
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Figure  1:  IMA  witli  its  environment 


to  meet  the  i'nnctional  and  availability  requirements  oi  the  avionic  liuiction.  An 
avionic  svstem  is  a  sul>set  ol  the  IMA  Host  S\’stem.  Avionic  systems  may  contain 
the  same  equipment  e.g.  the  aii'plaiie  bus. 

An  avionic  function  is  realized  by  wi'iting  a.  soltware  module  that  can  be  in¬ 
stantiated  as  one  oi'  more  collaborating  partitions.  Sex’era.l  soltware  modules  can 
be  written  to  satisfy  the  avioiiic  runction  specification.  These  modules  can  use 
different  avionic  resoui'ces  to  iru'ct  the  avionic  function  specifications.  Due  to  high 
reliabilit.y,  aA'ailability  and  hours  ol  working  after  first  lailure,  catastrophic  avionic 
functions  need  to  l)e  rc])licat.ed  o\’ei'  mor<'  than  one  cabinet.  Replication  is  handled 
in  two  ways;  (1)  installing  vrr.^ioii-^  oi'  (2)  installing  I'epUcas.  Two  partitions  are 
called  versions  iff  they  realize  the  sanu’  avionic  function  l^ut  with  different  soft¬ 
ware  modules,  d  wo  pa.it.ilions  aie  calk'd  replicas  ill  tliey  realize  the  same  avionic 
function  with  the  same  soft.wa.iv'  moduk'.  An  avionic  functions  that  is  distributed 
over  a  set  of  core  modules  is  realized  by  one  |)arfition  ])er  core  module. 


2.1  ARINC629 


TJic  A R  INC' spcH'iliciil  ii)ii  (129  [1]  (K'lim'sn  digital  comiiuiiiicat  ions  system  in  wiiicli 
icrininal.s  (Rl)('  aiul  eahinels)  may  Iraiismil  and  recc'is'e  digital  data,  using  a 
standard  prot  ocol  communicat  ('d  over  idect  I'i rally  condmi  ing  or  fiber  optic  media. 
Tl.ie  ability  to  (ransndt,  both  p('riodir  and  api'riodic  data  in  a  bidirectional  way 
is  ba.sic  to  the  design,  bach  tei'ininal  is  progranmu'd  to  scmd  data  during  globa.lly 
defined  interx'als.  d  wo  protocols,  the-  Ifasic  Ib'otocol  (RR)  and  tlie  Clombincd 
mode  Protocol  (CP),  support  |)oint-to-poinl  and  lu'oadcast  pi'otocols. 

Basic  Protocol  ’Idii'tH'  int.c'i-vals  aia'  delined  l,)y  tin'  protocol: 

•  Ti'ansmit.  Interval  (d'l).  common  It)  all  tei’ininals. 

•  Sytic  (ia].)  (SC),  a  (iui('t  inlc'rval  common  to  all  tei’iuinals, 

•  Terminal  Ca])  (dXI).  a  (|iiiet.  interval  iiniciue  to  eacli  teinninal. 

Each  iiuli\'idual  terminal  staits  'hi  when  it  starts  transjuitting  during  an  in- 
terva.l  smaller  than  d'l.  terminal  may  start  transmitting  when  an  interval  TI 
has  elapsed,  no  terminal  has  sent  data  dui'ing  interval  SC  and  during  its  personal 
interval  d.Tl  no  data  is  semt.  d  he  ix'idodicity  of  t  he  bus  is  determined  by  the  load 
and  the  definit.ion  of  the  thre-e  int ('I'Vids.  .All  tc'rminals  are  syriclirouized  with  each 
other  via  interval  SC.  d'erminals  do  not  intcud’ere  with  each  other  due  to  two  mech- 
a.nisms  de])endent.  on  the  mode.  In  tlu'  aperiodic  mode,  a  terminal  starts  when 
SG  ha.s  elapsed.  Because'  SC  is  attributed  uniciuc'ly,  oidy  oiie  t.erminal  will  start 
sending  at  a  gi\’en  time.  In  Ihe  pc'riodic  tnode,  a  terminal  ca..nnot  start  sending 
before  dT  has  elajesed  and  d.'l  is  diosen  longer  t  han  the  total  expected  tra.nsmission 
times  of  all  tei'minals  wit.hin  a  giw'ii  pc'riod:  d'l  >  MCdd  Alinitintm  Frame  Time 
(MET)  is  defined  as  the  sum  of  the'  luis  occu|)ation  int.ei’vals  of  t.he  terminals. 

Correct  functioning  of  jn'otocols  is  gnai'antee'd  by  timers.  Timers  are  never 
com])letely  synchronized.  In  the  pc'riodic  mode  this  lias  as  coiLsequence  that  the 
order  of  sending  within  a.  given  ix'i  iod  is  not.  always  tlic'  sa.ine. 

Dependent  on  t  he'  load  and  llu'  dc'linition  of  d^l,  all  terminals  either  execute 
the  periodic  oi'  the  a.]U'riodic  protocol.  Protocols  cannot  be  combined. 

An  example  ol  a.  periodic  I  iming  diagram  is  shown  in  l''ig.  2. 

Combined  Mode  Protocol  d  lu'  CP  protocol  use's  the  same  three  intervals  de¬ 
fined  above.  Additionally  thrc'c'  Ic'wls  aii'  delined  in  which  periodic  and  aperiodic 
messages  can  be  combined  wit  hin  oiu'  [x'liod: 

•  level  1:  periodic  iru'ssagc's 

•  le\'el  2:  iidVi'cpu'nt  high  priority  iiK'ssagi'S  (short  dni-alion) 

•  level  .’f;  low  prioi'ity  apc'riodic  nu'ssagc's 


MU  '  I  k'iiiiiii;iI  I 


IVniiin:il  ^ 


M  = 

Ml'f  =  Mijiiimiin  rmiiU’  Tiriu* 
MU'  =  Mlnni  ri'ailK" 

Tl  =  TiaiiMiiii  liiii’i 
SC  =  SyiK’lit'iiiii/alioii  ( la)' 
TG  =  Torihiiial  (iap 
Ti  >  Mrr 


Figiii'c  2:  Possible  liming  diagi'aiii  lor  ARINCJ  029  i)rotocol 

During  a-  ])ci'iod  a  lerniinal  may-  scud  only  one  level  I  and  level  2  message. 
Level  3  message's  can  have  an  nnspc'cilied  dniatlon  and  as  man}'  as  needed  can  be 
sent.  The  duration  ol  le\-el  1,2  and  3. message's  within  one  period  is  bonnded. 

2.2  ARINC659 

A  replicate-xl  bus  based  on  the  AHl.\('(ih9  slandard  [3]  provides  the  communication 
between  LRAI’s  in  a  calnnc'l..  d  ransmissions  and  le-ece'ption  to  and  Irom  the  bus 
are  table’  drive'u.  File’  tal)les  ol  all  LUIM  s  in  one'  cal)inet  ne’ed  to  be  the  same 
for  consiste'ncy  reasons.  13ns  time'  is  divided  in  a  se'riefs  ol  windows,  each  window 
containing  a  single'  me’ssage'.  Data  is  translerre'd  according  to  a.  predetermined 
transl'eu'  schc'diile'.  "Fables  de'line'  the'  le'iigl  h  ol  c'acli  window  and  the  transmitter(s) 
and  rece’i vc'r(s)  within  this  winelow.  Iransle'r  is  gnaranteed  under  se’v’eral  lailuie 
conditions.  Idic'  Fnis  Iransle'r  sclu'diile,'  is  organizc'd  in  cyclic  loops  of  constant 
length  set  by  the  sum  of  the  inflix’ielnal  window  lengths.  A  possible  table  setting 
for  a  given  LR.M  is  shown  in  Fig.  3. 

Each  windo\v  has  e'il  lu'r  an  nnie|ne'  t  ransmil  te’r  or  a.  limited  set  ot  candidate 
transmitters  ol.ieying  the'  Masle'r/Shaelow  pre)t.e:)cc:)l.  When  tlie  master  starts  send¬ 
ing  at  the  allocale.'d  tame',  no  eitlu'r  shaelow  Iransmitte'r  l.ransinits.  If  the  mastei 
and  seame'  sliade:)ws  lail,  the  first  ee)rre'ct  se'he'dnle'd  sha.elewv  transmits  a.  message, 
all  later  scheduled  sln-ide-aws  eh)  ne)t  t  ransmit'. 

\V"indovvs  are  organize’d  in  cye  lie-  Iraines.  Meare'  than  enie  Iraine?,  possibly  cor¬ 
responding  with  diire’renl  flight  phase's,  is  ])re)gramine-'el.  Special  control  messages 
are  forese'e'ii  to  change'  lrc)m  a  give'ii  frame'  le)  anerlhe’r  one’  in  a  controlled  manner 


{) 


Figure  '■]:  I’ossihle  tahli'  organizat  ion  foi'  AH  INC  059  protocol 


for  all  LHM’s  in  calrinet, 

3  IMA  Software  Architecture 

An  a.vionic  function  needs  two  types  of  inatcvrial  resoni'ces;  (1)  control  resources: 
control  system  hardware  needed  for  its  ('xecntion  (shaded  area,  in  Fig.  1)  and  (2) 
avionic  resources:  actna.toi's  and  sensors  that  are  needed  by  the  avionic  functions 
to  establish  the  position  and  movc'inent.  of  the  aircraft  (Non  shaded  area  in  Fig. 
1).  The  results  pi'odnced  by  a  |)artilion  can  senve  as  input  to  a.nother  partition. 
When  functions  are  replicated  over  versions  or  replicas,  the  results  of  correct 
partitions  should  l)e  identical  or  wil  hin  a  given  ra.Jige.  When  results  of  resources  or 
partitions  are  wrong,  it  is  imporlant  to  detect  this  a.nd  ascertain  its  cause  for  later 
maintenance.  When  tlu'  failures  of  resources  or  partitions  are  detected,  a  pa.rtition 
can  decide  to  ignore  t  he  associatcal  resulls.  When  a  |')artition  ignores  a.  result,  the 
other  partitions  using  the  same  results  should  equally  ignore  them  to  a,rrive  a,t 
the  same  results.  (Consequently,  it  is  impoi'tant  to  estal,)lish  tlie  set  of  correct  a.nd 
incorrect,  results  in  aconsistcnii  maman'.  (Consistent  mea.ns  that  the  related  results 
of  collaborating  |)art.itions  ari’  based  tjii  the  same  input.  Two  exa.mple  show  how 
inconsistent  input  can  hxul  to  wrong  results  aiul  hidden  dependencies. 

Example  1:  Suppose'  a  funetie)!!  is  re'alized  with  thi'ee  replica.s  that  exchange 
their  results  and  vote  on  the  outcome'.  When  all  three  rej)licas  are  correct,  they 
should  arrive  at.  the  same  residt  anel  whe-n  a  replica,  receives  two  dilTering  results 
it  can  conclude  that  tlie  I'e-sults  that  ele\’ia.t.(^s  li'om  its  own  result  is  sent  by  a 
failing  replica..  However,  such  a  situation  can  also  occur  wlien  inconsistent  I'esults 
are  received  ly\'  the  re|)licas.  W  lu'n  inconsistent,  lesults  a.ie  received,  either  a.n 
incoi'rect  detection  of  a.  failing  replica  is  made,  or  the  detection  of  failing  replica.s 


is  never  done. 

Example  2:  Su[)[')Ose  a  liiiiclioii  is  r('aliz('<.l  with  two  \’ei'sions  tliat  use  some 
similar  and  some  dillerent.  resource's,  h.aeli  oik'  ee'i'ific's  I  he  correct  ness  ol  the  input, 
calculates  results  and  compares  with  tlu'  lesulls  ol  the  other.  Sipeieose  the  input  ol 
the  common  resource  is  dilh'renl.  1  lu'  x'orsions  may  pi'odnce  inconsistent  results 
tha.t  lead  t.o  the  siippi’essioii  c)l  the  whole  lunctaon  or  may  start,  wrong  actions  it 
one  of  the  other  unique  input  rc'sidts  is  un-detectahly  wrong.  tD 

A  recpnremc'nt.  on  the'  conimuincat  ion  hetwec'ii  rc'sources  and  partitions  and 
between  pai’t-itions  can  l)e  lormulalc'd: 

Reejuirement  1  All  vepheas  or  n  rsioiis  colldhoi'ol nip  on  some  rclotcd  results 
should  read  the  same  irstdl  coniinti  Ji-oin  a  particular  resource  or  partition 

Below  the  failure  hypotheses  ou  tlu'  IMA  hai'dware  components  are  enumer¬ 
ated.  A  soft-ware  archii.eci ure  is  proposed  that  satisfies  the  above  requirement  1 
and  does  not  introduce  other  lailnrc'  (h'pc'iuh'ncic's  a|nvrt.  li'om  the  ones  cited  below. 


3.1  Failure  hypotheses 

During  operation  ol  the  aircralt..  hardware  may  lail.  A  core  module  has  a  lail-stop 
behaviour;  its  behaviour  sat  isfic's  it  s  specification  until  a  given  moment  alter  which 
the  core  module  does  not  perform  any  olrservalrle  action.  When  a.  core  module 
fails,  all  the  partitions  executing  on  the  core  module  are  assumed  to  fail.  When 
all  jrrocessors  counected  to  a  resource'  tail,  the  connected  resource  is  assumed  to 
fall.  Wlien  the  local  clock  of  a  core  module  fails,  the  coi'e  module  tails.  When  the 
power  to  a  cabinet,  all  gatewae  s  or  the  Irack])!^^  bns  ol  a  cabinet  fail,  the  cabinet 
is  assume'd  to  fail.  W  hen  a  cabinet  lads,  all  resource's  connected  to  this  cabinet 
and  all  core  moduh's  ol  t  his  cabiiu't  lail.  VVlien  the  airplane  Inis  fa.ils,  the  complete 
avionic  system  is  assumed  to  lail.  .A  |)ai'tition  lias  lail-stop  behaviour.  When  a 
partition  fails,  no  other  comiioiK'uts  ol  the  IM.A  system  are  assumed  to  be  affected. 
When  the  ])rivate  memory  of  a  partition  fails,  the  partition  fails.  Shared  memoiy 
can  be  divided  in  comiionents  with  inde|)endenl.  fail  characteristics.  When  a.  part 
of  a  shared  memory  component  lads,  the  whole  shared  memory  component  is 
assumed  to  tail.  W  hen  all  shared  iiH'morv  comjionents  ol  a.  core  module  fail,  the 
core  module  is  assumed  to  lail. 

The  hardrvare  lailure  probabilil  ii's  must,  be  calculated  such  that  they  are  infe¬ 
rior  to  the  reliability  r('(|uirenu'nt s  ol  t  he  tnnclions  tlu’y  support. 

3.2  Communication  structure 

Two  communication  models  are  generally  a|.)])lied:  (1)  partition  (consumer)  in¬ 
terrogates  a  result,  producing  partition  or  resource  (producer)  to  return  a  result 
or  (2)  the  jiroducer  sends  at  well  est alilished  moment,  results  to  the  known  con¬ 
sumers.  The  above  recpiirement,  1  prohibits  most  communication  models.  Under 
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model  1  several.  ])ossil)ly  diUc'i'iiig.  |■('s^lts  are  produced  by  tlie  jH'oducer.  Es- 
j^ecially  wlieii  (be  producer  can  fail,  some  coiisuiiK'rs  r('C('i\’c  a  result  and  others 
none.  For  a.  large  numl)ei'  of  axuonlc  fuiiclious,  prodiicei's  know  their  consumers. 
It  is  therefoi'e  preleraldc'  (hat  prodnci'rs  send  (he  sanu'  result  (.0  all  consumers. 
When  a,  producer  scuds  a  rt'suh  (o  cat’ll  indi\’idual  consumer,  the  iailing  of  the 
producer  can  lead  (o  (he  unwanted  si(ua(ion  (ha(  some  consumers  have  received 
the  result  and  odiers  no(.  ’Vlie  |■)es(  known  solid  ion  is  (o  use  a  reliable  multicast 
protocol  in  which  (.he  product'!’  st'iids  out'  I’t'suh  once  and  the  protocol  guarantees 
that  eitlier  all  correc(,  coiisuniers  i’ecei\’t'  (he  ro'sult  or  none  does  [5,  7].  Results  are 
sent  to  jM’oeessors  wliere  (lu'v  are  s(oretl  in  shared  memory  at  the  disposal  of  the 
interested  partitions.  C.xa.mpit's  of  reald  iine  sys(.cm  where  this  basic  as^ynchronous 
approach  is  followt'd  are:  [8,  b  10.  0] 

This  design  satisfies  (lit'  i’et|uii’emeu(  1.  all  producers  send  one  result  to  all 
processors;  relaled  correc(  par(  i(  itiiis  will  reatl  (he  same  I’esults  as  long  as  their 
reading  momenl  is  ct)i’i’ec(ly  synchi’oni'/t'd  willi  (lit'  a.ccep(ance  moment.  By  cal¬ 
culating  the  ma.ximum  ( ransinissitui  (  imt'  and  waidng  an  appropriate  time  with 
respect  to  the  sending  time,  such  a  syiuhronizat ion  is  achieved.  When  one  par¬ 
tition  of  a  processor  fails,  the  resuhs  remain  available  in  the  shared  memory  and 
other  partilious  (in  (he  same  processoi’)  are  not  airectecl  b_y  such  a  failure.  When 
the  communicatiou  falls,  all  involved  pardtious  will  fail  as  mentioned  above,  and 
when  the  shared  memory  falls,  no  resuhs  are  available  and  (lie  processor  with  all 
its  partitions  falls. 

When  producers  fall  no(  by  s(i,)pping  bid  by  producing  incorrect  results,  their 
results  sliould  no  be  a.ccep(ed.  bailurcs  can  b('  de(('ctable  on  several  levels. 

1.  The  resource  failure'  can  be'  de'( e'c( able  at  (he  t’e'source  itsedf  by  introducing 
redundancy  clu'e’ks  a(  (he'  source. 

2.  A  software  layer  on  (.op  of  die'  |)hysie’a.l  resourc’e  can  check  tlie  correctness 
of  the  ]’>rodue'eel  re'suKs. 

3.  A  tes(.  program  e-an  a.syue’lireuiously  with  the  centred  programs  a.cce.ss  re¬ 
sources  and  cliee’k  (  heir  (’oi'i’e'(’(  fuiie’tie’ming. 

4.  A  |)ai’(.i(  ion  e’an  e’ouchiele'  (  hat  a  l  e'siih  is  iiu’orrea’t,  by  com])aring  the  result 
with  re:'sult.s  from  fune’tionally  e'e|iii\’alent  prodiu’ers. 

5.  Core  module's  e’aii  detect  (hat  a  core  me)dule'  or  transmission  channel  falls. 

In  case's  1  and  2,  t  he'  correct  lu'ss  of  a  ri'sult  can  be  dete?rmined  before  the  result 
is  multicast  to  its  consumers.  B>’  adding  (  he  status  of  the  resource  to  the  produced 
result,  all  partitions  take'  the  same'  eh'cisiou  on  the  refusal  or  acceptance  of  the 
requested  results.  Ilowen’cr  in  e’ases  3-5.  a  distribution  of  failure  information  that 
is  synchronous  with  the  result  elist  rilud  ion  is  much  harder  to  realize.  An  example 
will  show  (his. 


Excimple  3:  Siipptjsc  a  rcsnll  is  scail  al  tiiiio  /,,  and  rcMa'iNTcl  and  stored  on  all 
pvoccssoi'  1 1  K'li  loi'K's  a  t  liiiK'/,..  .\  paiiilK'ni  [>  will  lavul  these  rc'siilts  at-  (inie /p  >  1,-. 
Suppose  a  failui-e  is  (l('l<'cled  in  llu'  result  producing  la'source  and  is  eoniniunieated 
to  all  processors  at  time  I  f  ^  Ir-  It  c'asy  to  sec'  that  the'  partitions  cannot  lea.d 
the  result  at  t  he  same  time'  /,,  and  that  for  some'  partitions  p  :  /,,  <  ij  and  lor  other 
])a.rtitions  p  :  /,,  >  If.  thus  \-iolating  tlu'  consistc'iicy  re(|uir('ment  unless  special 
measures  are  taken.  ^ 

The  mcmh('rshii')  ser\dce  can  lu'lp  to  solve'  this  prohlc'in.  I  he  realization  ol  tlie 
memlrcrshi service  [(>]  ('xteruh'd  to  hic'rardiical  communication  structuies  [11] 
and  adapted  to  a\lonics  [12]  is  descilhc'd  below. 

4  Membership 

A  consistc'ut  distribution  ol  I'aihirc'  inlormation  is  lormiilated  in  the  lollowing  re¬ 
quirement: 

Requirement  2  All  rcplicns  oi'  versions  collnboi'dliiifj  on  some  reloted  results 
hove  the  some  opinion  on  the  coi-reet ness  oj  a  piriiicular  resource  or  porlition 

By  considering  llu?  set  ol  corrc'ct  rc'sourcc's  and  partitions,  the  above  require¬ 
ment  can  be  rr'Ibrmulated  as  t  lu'  llu'  membership  re(|uirenu^nt  by  asking  tliat  every 
partition  has  tlie  same  view  on  tlu'  memlrcrs  ol  the  set  ol  correct  partitions  and 
resources.  The  normal  design  ap|)roach  is  to  assure'  that,  a  processor  has  a  view 
on  the  mo'mbership  sr-'t  and  all  corrc'ct-  |)art  il  ioiis  e.xc'cuiing  on  tliis  processor  share 
the  same  view.  The  monu'iits  t  hat  a  \l('w  ol  a-  gi\’en  procc'ssor  clianges  is  defined 
with  res]x'ct  to  the  local  lime  of  the  processor.  .4  membership  algorithm  realizes 
this  common  view  on  the"  membe'rship  sc't .  llu'  r('(|uirements  on  the  membership 
service  arc: 

Requirement  3  Membership 

•  At  identical  local  clock  times,  the  inevihership  view  of  any  two  correct  pro- 
ccs'.scr.s  is  identical. 

•  Resources  and  partitions  that  an  detected  to  jail  by  o  processor  p  o.t  local 
time  t  are  removed  jrom  tin  iin mix  I'slnp,  set  within  a  bounded  period  J ,  at 
local  limes  t  +  ./ 

•  Correct  resources  and  pa  rt  it  ions  are  not  removed  Jrom,  the  memhership  set 

The  storage  of  a  new  re'sult  in  shared  memory  depends  on  the  jrresence  ol  the 
producei’  in  the-'  me'inbersliip  se't.  /\ssumc  a  constant  l\  such  that,  a,  sent  result 
arrives  at  the  de'stinatioii  proce'ssor  p  at  a  local  time  +  A  .  When  a  result 

-sent  at  Ureal  lime'  arri\’e's  in  a  |)ioce'ssor  at  local  time"  /,  tlie  result  is  stored 
in  the  share'd  menurry  ol  the'  re'ce'i\liig  prerce'ssor  at  local  l  ime.'  /,•  =  A  +  -A  if  the 
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]')roclucef  of  tlu'  rc'sull  is  ;i  iiu'iiihiT  ol  iIk'  luontlioi'shii)  sot  iit  K)c';vl  t.iiiie  The 
rcalizaXion  of  llu'  iiu'niln'i'slii|)  alka  li  Inn  ami  tiu'  caloulaf  ion  ol  coiist  anl-s  l\  and 
J  is  the  suli’n'cl  of  the  ik'xI  siihsocl  iuii. 

4.1  Membership  realization 

It  is  assuiiK'il  that,  during  any  nu)nu'nl  any  1  wo  eoi'roet  |)roeossors  can  coininnnicate 
with  each  other.  I'liis  assiiin|)l  icjii  is  jnsliliod  hy  the'  lailnro  hyi)othosi.s  that  tlic 
failure'  of  t  lio  coniinnnicat  ion  iK'twoi  k  implii's  t  he'  laihire'  ol  t  he  complete  IMA 
system.  It  is  assumed  that  tlu'  failure  detection  ol  re'sources  does  not  detect 
failures  for  corrt'ct  lesource's.  Pix)l)|em  is  to  dc'te'rmiiu'  that  no  correct  cabinets 
or  processors  with  thc'ir  counect('d  rc'sonrcc's  arc'  rc'inov'od  Irorn  the  membership 
set.  As  long  as  thi're  are  coi'i'c'cl  procc'ssoi's.  tlu'  meml.K'rshi[r  algorithm  needs  to 
satisly  re(|uii'('nu'nt.  d.  d'lu'n'loi'o.  cc'iil  ralizc'd  solutions  ai(' excluded.  Replication 
of  tlie  juembei'ship  stale'  o\’er  all  corrc'cl  core  modules  is  a  consequence.  When  a. 
pa.rt.it.ion.  core'  module'  oi’  cabinet  lails.  t  he'  me'mbe'i'shi])  slate,'  re'inains  updated  in 
a.ll  surviving  core'  module's. 

Tlie  memlre'rsh i |)  algorit  hm  eanisisls  e)l  a  <l(  Ifclioii  part  and  a  d islribation  part. 
The  failures  of  proc'cssors  and  partitions  are'  de'te'cled  by  having  each  processor 
send  mc'ssage  to  asce'rlain  it  s  cen  re'e  l  ne'ss.  d  he'  messages  cont  ain  inlormation  about 
failed  re'source's  and  part  it  ions  to  elist  ril)ule'  t  he  failure  inlormation.  Partitions 
that  dctc'ct  the  failures  of  other  peer!  it  iems  or  resource's  communicate  this  to  the 
memb(?rship  se'rvice  ihal  is  respe)nsible'  loi’  the-  lime'ly  distribution.  Tire  moment 
tha.t  failure  informat  ion  is  ce)nmmnical.e'el  to  t  he'  membe'rsliip  service,  is  defined  a,s 
the  faihii'e  dete'ctioii  lime. 


Design  Pa.i'l.ilions  are  re'spenisilile'  for  monitoring  the'  I'ersoui'ces.  Every  ca.binet 
is  responsible  for  monitoring  the'  stale'  of  the'  partitions  and  core  mochdes.  The 
membershi|)  algorithm  is  i)e'riodie-ally  exe'cuted.  Pour  pliase's  are  discerned:  a 
gathering  phase',  a  colle’cl  ion  phase',  a  disl  ribnl  ion  |)hase  and  an  information  phase. 

In  the  CdlhfriiHj  phase',  partitions  actix’e'ly  iid'orm  the  membership  service 
of  resource'  failure's  and  pai'lilion  crashe's  by  im'oking  lunclions  that  store  this 
information  in  ihe'shaiv'd  rne'inoiy  (not  the'  me'inbership  state)  of  the  core  juodule 
hosf  ing  tlie  dele'ct  iiig  partit  ion. 

In  the  Coihclion  plmse'.  tlu'e  eire'  nu)elule's  commnnicate  the  failure  information 
at  a  prcari'ange'el  local  lime'  to  all  olhe'r  ce)re'  modules  in  the'  same  cabinet  via.  the 
cabinet  bus.  Whe'ii  no  failure'  information  is  |)re'se'nt,  t.he  core  module  seiids  an 
el^lpty  message.  The  failure  of  a  core'  module'  to  send  a.  message  is  interpreted 
by  the  other  core'  module's  as  ii  coi’e'  module'  failnie.  'Po  assure  that  all  correct 
core  module's  within  the  caliiiie't  re'ce'ixe'  the  same'  message  or  none,  a  reliable 
muflicasl.  is  needed  as  alre-ady  me'iilione'd  above'  for  t  he'  transmission  of  results  by 
producers.  VYlu'ii  a  ceue  module'  doe's  not  se-nd,  the'  core'  module  ha.s  crashed,  its 
shared  memory  has  crasheel.  oi'  its  local  cKrek  ha.s  clashed.  This  is  in  accordance 
with  tlie  luu’dware'  failui'e  h\’pe)l  he'sis. 


Ill  t  lu’  1) isl I'll) If! K) n  |)li;is('.  ;ill  ciilniu'is  disl  i'il>iil(' I  lu' caliiiuM  s  laihu'c  iiifornia- 
tioii  to  all  Ollier  calniuis  \’ia  llu'  airplane  Uiis.  When  no  lailno'  inlorinataon  is 
])i'eseiit..  the  cahlnel  sends  an  einpl\'  message.  I  lu'  I .lauh'r/Slnulow  int'clia.nism 
is  used  to  (’omimmiealo  the  laiinre  iiilormat  ion.  .\ll  coiaa'ct  eoia'  modules  in  a. 
gi\a.ni  cabiiK't  liax'e  t  he  same  lailiii'e  inloi mat  ion.  ('on.s('(|n('nt  ly.  t  he  leader  and 
shadorvs  will  send  tlu'  sanu'  inrormalion  to  other  cahiiu'ts.  All  core  modules  ol 
Idle  destination  cahiiuM  r('cei\’('  the  nu'ssagc'.  W  hen  a  cahiiud  does  not,  send,  either 
all  its  gat('\va\’  moduh's.  its  |)ower-sn|)|)ly.  its  hachplaiu'  hus  or  the  leader  and  all 
shadows  ha\'e  laih'd.  1  his  is  in  accari’daiua'  with  tlu'  haialwai'c  lailni'c  hy])olhesis. 

In  tlu'  fn fornuil ion  phase,  all  coi'rc'cl  core'  modules  install  tlie  new  member¬ 
ship  state  at.  the  sanu-  local  clock  limes.  .Ml  c-orrei't  core  modules  ha.ve  received 
the  same  failure  informal  ion.  .Ml  corrc'ct  core'  modnh's  had  ihie  same  member- 
shiip  stat.c'.  ( 'ons(H|uenl  ly.  alien'  llu'  iiilejrmal  ie)n  phase  all  core  modules  ha.ve  the 
sanu'  membe'rship  state.  W  luni  llu'  nu'inbtn'ship  stale'  change's,  all  coi'rect  modules 
change  stale'  at  the'  sanu'  hre'al  e'loe'k  time'. 

Performance  d'e)  salisly  the'  I'e'al-time'  crite'ria.  a  well  de'fine'd  time  bound  be¬ 
tween  message  I  ransmission  anel  nu'ssage'  I'ce'e'pl  ie)n  must  be  assured.  The  Airplane- 
bus  give's  such  a.  bounel  only  Idr  pe'rierelic  me'ssage's.  Ceensecpiently,  every  ca.binet 
transmits  its  vie'W  |)erie)elie'ally  e'N'e'iy  tt  time  units. 

Frerm  t  he  cemmnmie'at  iern  de'sci'i pi  ie)ns  it  e'an  be'  cernclneleel  that  the  commu- 
nicatiern  within  a.  e'abiiu'l  is  slrn  tly  sy ne'lirernize'el.  but  cemimunication  between 
cabinets  is  sensiti\'e’  ter  e']e)e'k  drills.  1  he'  t. lining  ol  the'  me'ssagc'  transmission  be- 
tw’een  cal,)i,ne'ts  elrilts  with  re'S|)e'e'l  to  the'  e'abine't  bae’kphvne  bus  schedules.  This 
adversely  aflecis  the  transmissiein  ele'lay. 


[) 
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f’liysical 


If  h  b  h-  A 

CiibiiK'l  c  _ I - 1 - j - 1 - j- 


bi  h  Ai 

CeibiiK'l  el  _ | - 1 


h'ignre'  1:  (.'eriimiiinie'at  le)n  ele'la\'  leir  me’mliershij.D 

A  timing  eliagram  is  she)wn  in  k'ig.  I.  The'  |)e'riexl  ol  Ihe^  airplane  data  bus  tt 
is  smaller  than  the'  [le'rierel  tt,.  e)l  the'  liaekplane'  bus  e)l  any  gi\'e:'n  cabinet  c.  Every 


leacler/whadow  ti'aiisniils  I  Ik' caliiiK'l  iiiU)i'inal  iun  .s',.  —  [tt,./?:]  times.  Suppose  a. 
core  module  in  eahiiu'l  r  deh'tis  a  lailiiii'  at  local  time'  During  t.lie  coltectJon 
plia.se,  this  coi'e  module'  Irausmils  llu'  lailui'e'  on  the'  caliiiie't.  data,  l.nis  at.  local 
time  C\~.  I'he  e'ollection  phase'  stai'ts  alter  the'  ele't e'e'l.iein  phase  with  a  ma.xdmum 
dela.\’  given  by:  D,- +  ^  >  (  'r  >  -  -^t  leiead  l  ime'  f  [-.  de'le'rmiiie^d  liy  the  timing  ol 

the  airplane’  l)iis.  the  re'snils  are-  I  I'ansmil  le-el  te)  the'  re'cei\’ing  cabinets.  Neglecting 
the  l.ransmission  delay,  the'  nu'ssage-  arrie’e's  at  e'abine'Is  c  and  e/  at  globa.l  time  T, 
that  is  t.he'  same'  lev  bol.h  cabiiu'ts  as  iIk'X’  are  e'oinu'e'le'il  by  tlie  sa.me  a.irplane 
bus.  Although,  transmission  ere'eaiis  at  t  he  same  physlearl  time, the  local  clocks  Tc 
a.nd  I'd  diller  by  a  value'  t:  |  T,  -  T.j  \<  e  .  'hlie'  pe'riodicity  of  the  airplane  bus 
introduces  a  max'imiim  delay  of  tt:  7',.  —  ~  <  (\~  <  7,..  .A  me’ssage  sent  at  local 
time  Tc  is  received  at  times  aiul  /.,/  by  core  meDelules  in  cabinets  c  a.nd  d  with 
the  restraint,  (.r  =  c  or  .r  =  e/)  :  77  <  <  T-  +  When  both  cabinets  follow 

the  same  frame  orgauizatiein .  the  xabu’s  ed  l.c  and  /.,/  are  identical  but  have  a. 
spacing  of  appi'oximalelv  e  time  units,  d'he  acceptance  ol  tlie  message  by  a.  core 
module  in  cabinet,  d  is  doin'  at.  linu'  .•I,/  such  thal,  V.r  :  /!,/  >  This  leads  to: 
71/  +  TT  <  Ad  <  Td  +  2  •  TT.  .According  to  the  meml.K'rship  requirements,  the  vcvlues 
Ac  and  Aj  an'  ident.ical  but  occur  at  different  physical  limes  placed  within  an 
interv'al  of  appro.ximately  c.  Ilxpn'ssed  In  local  times  the  difference  between  Dc 
and  Ad  is  gi\'en  by: 

TT  —  (  <  Ad  —  Dc  <  2  •  ;r  +  f  (i) 

Assuming  that-  clocks  dilfl  little  with  i’es|)ect.  to  the  physical  clock  in  interval 
e,  The  following  constraints  an;'  t  rue': 

\n-Dc\<(  |<c 

Tlie  total  physical  l.ime  is  gixK'ii  by: 


TT  -  (  <  .4  -  I)  <  .4(7r  +  c)  (2) 

5  Conclusions 

Avionic  functions  are  lealizi'd  rvith  an  l.\l.A  archit.i'cture.  The  strict  hardware 
separation  of  functions  of  dillen'ut.  miticalily  levi'ls  is  no  longer  an  interesting 
option,  llesources  are  sharc'd  and  ('specially  the  communication  media,  between 
dill'erent  core  moduh's  must  bt'  shared.  lm|)orlanl.  is  the  prevention  ol  lailui’e 
propagation  b('t\V('en  comiioiu'iits  with  a  low  criticality  level  to  a  high  criticality 
level.  It  is  argued  that,  partitions  (w'lsions  or  replicas)  t.hat  collaborate  to  pro¬ 
duce  the  same  result.s  lux'd  the  sanu'  input  data.  .A  communication  structure  is 
defined  t.hat  sa.l  isfic's  I  his  re(piirem('nt  and  dc'iiends  on  the  availability  ol  a  reliable 
multicast  facility  wit  h  liouinh'd  transmission  limes.  It.  is  shown  that  the  hardware 
determined  failun'  hx’pot lu'sr's  an'  not  exlc'iuh'd  by  t  his  structure. 


'J'lie  iiil  rodiu'l  ioii  uf  I'ailuiH's  aiul  ilu'  ixHiiiiia'iiK'iit  t  hat  collaliorat  ing  part  itions 
consider  tlio  same'  rcsoii I'lcs  as  laiKsl  ai  llu'  sanu'  inonu'iit  can  he'  K'ali/od  with  a. 
niembci'sli  1  p  algorithm.  ,\n  outline  ei  the  algtirithin  is  prosi'nlcd  and  it  is  shown 
liow  the  lailnrc'  hvp<.it  lu'sc^s  arc  iiiaiiilaiiuHl.  Kcsults  arc'  only  jiossible  il  bounded 
transmission  time's  are  possilih'.  1  In’  re'(|uiri'd  bounds  are'  iire'se’iited  as  iimction 
of  the  Il\lA  conmuinicat  ie)n  nu'elia  e'harae'te'iist  ie's. 
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A-bstrflct 

This  paper  deals  with  the  modeling  of  VHDL  behavioral  descriptions  and  the 
development  of  an  efficient  behavioral  fault  modeling  scheme.  A  set  of  behavioral  test 
pattern  generation  methods  have  been  proposed  in  the  recent  past.  One  constraint 
having  to  be  pointing  out  is  the  fact  that  circuits  under  test  (CUT)  are  expressed  using 
a  high  level  behavioral  VHDL  description.  We  propose  to  define  a  behavioral  fault 
simulation  method  own  to  (i)  a  behavioral  modeling  of  CUT  using  Petri  Nets  and  (ii) 
an  efficient  behavioral  fault  modeling  scheme.  In  this  paper,  the  emphasis  is  put  on  the 
modeling  aspects. 

Keywords  :  Behavioral  Descriptions,  Behavioral  Fault  Modeling,  Petri  Nets,  Fault 
Simulation 

1  Introduction 

In  the  recent  past  a  set  of  Behavioral  Test  Pattern  Generation  methods  have  been 
proposed  in  several  international  conferences  [1,  2,  3,  4,  5,  6,  7,  8].  Motivated  by  this 
fact  we  are  interested  in  defining  an  efficient  behavioral  fault  simulation  methodology. 
One  important  constraint  within  which  we  have  to  work  is  the  fact  that  circuits  under 
test  (C.U.T.)  are  described  using  a  high-level  behavioral  description.  The  previous 
work  has  focused  on  the  A.T.P.G.  method  and  not  on  the  fault  modeling  and 
simulation  tasks. 

Our  goal  in  this  article  is  to  present  an  efficient  modeling  and  fault  modeling 
scheme  for  behavioral  descriptions. 

The  first  part  of  the  presentation  is  devoted  to  general  definitions  of  modeling 
and  fault  modeling.  The  second  part  will  deal  with  behavioral  modeling  of  VHDL 
descriptions.  The  definition  of  an  exhaustive  behavioral  fault  modeling  scheme  is  given 
in  the  third  part.  Future  work  concerning  behavioral  fault  simulation  is  briefly 
introduced  in  the  last  section. 

2  General  definitions 

The  modeling  of  a  circuit  can  be  done  according  to  two  points  of  view  :  a 
structural  view  and  a  behavioral  one.  We  focus  on  discrete  models.  The  use  of  a 
discrete  model  to  solve  a  given  problem  refers  to  a  set  of  discrete  variables  called  State 
Variables  which  define  the  State  Space  of  the  model.  The  behavior  associated  with  the 
model  is  necessarily  expressed  through  the  alteration  of  the  variable  values. 
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In  case  of  a  behavioral  view,  the  circuit  is  seen  as  a  black  box  defining  its  output 
values  according  to  input  values  by  the  use  of  algorithms,  true  tables,  state  tables  or 
boolean  equations. 

Behavioral  models  can  have  two  main  representations  : 

.  alphanumeric  representations  :  they  are  textual  representations  involving 
objects  such  as  variables,  operators  and  control  constructs. 

.  graph  representations  :  they  are  based  on  transformation  graphs,  Petri 
Nets,  etc...  .  These  representations  offer  a  structure,  i.e.  an  interconnexion 
of  basic  elements  for  which  a  behavior  is  predefined  out  of  context.  We 
have  to  point  out  that  this  structure  is  not  a  potential  structure  but  some 
elements  can  have  a  physical  interpretation. 

Whatever  the  general  principle  on  which  the  Test  Pattern  Generation  (T.P.G.)  or 
Fault  Simulation  (F.S.)  methods  are  based,  structural  or  behavioral  models  of  the  circuit 
under  test  are  considered  as  the  reference  or  faultless  model. 

Given  a  description  (structural  or  behavioral  view)  of  a  circuit,  the  T.P.G.  or 
F.S.  method  has  to  operate  on  the  information  available  by  the  description.  In  both 
cases  fault  models  are  needed  in  order  to  represent  physical  failures  efficiently. 

Before  dealing  in  detail  with  behavioral  fault  modeling,  we  propose  some 
definitions  of  a  fault,  a  fault  model,  an  error  and  a  defect  in  order  to  guide  the  reader 
towards  behavioral  fault  modeling. 

A  fault  can  be  defined  both  on  a  structural  and  a  behavioral  model.  In  the  case 
of  the  use  of  a  discrete  event  model,  a  fault  hypothesis  is  : 

.  either  an  hypothesis  of  a  wrong  item  behavior  belonging  to  the  model,  but 
considered  out  of  context. 

.  or  an  hypothesis  of  modification  of  the  initial  global  description  by  adding, 
suppressing  or  combining  basic  items,  without  modifying  the  predefined  behavior  of 
these  items. 

A  fault  model  is  the  list  of  the  selected  fault  hypothesis,  i.e.  the  fault  hypothesis 
taken  into  account  for  T.P.G.  or  F.S.  There  are  several  interests  in  using  a  fault  model. 
The  main  one  is  to  reduce  all  possible  combinations  of  T.P.  sequences  at  the  input  of 
the  circuit  under  test.  The  definition  of  fault  hypothesis  allows  the  definition  of  fault 
classes,  the  reduction  of  the  list  of  selected  faults.  Furthermore,  a  fault  simulator  can  be 
used  to  determine  all  the  faults  set  off  by  a  given  test  pattern.  Lastly,  an  hypothesis  may 
be  used  to  make  a  correlation  between  a  fault  and  a  physical  defect  which  is  useful  for 
fault  localization. 

It  should  be  pointed  out  that  the  modification  of  the  global  description  of  the 
model  may  lead  to  take  into  account  a  much  too  large  number  of  possible 
combinations.  In  a  similar  way,  the  overly  complex  faults  concerning  the  modification 
of  a  basic  items  behavior  may  also  not  be  taken  into  account. 

Whatever  the  given  abstraction  level,  an  error  is  the  manifestation  of  a  fault 
expressed  as  a  difference  between  the  state  of  the  fault  free  model  and  the  faulty  model 
at  a  given  time.  If  it  is  not  posssible  to  obtain  a  difference  between  the  two  models,  the 
fault  is  said  to  be  redundant. 

A  defect  refers  to  a  physical  anomaly  of  the  actual  circuit.  It  should  be  pointed 
out  that  a  fault  may  or  may  not  have  a  direct  mapping  with  a  physical  defect. 
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3  Behavioral  Modeling 

In  order  to  facilitate  definition  of  formal  methods  based  on  graph  structures,  we 
have  been  interested  in  a  first  step  to  study  an  efficient  graph  modeling  of  behavioral 
descriptions.  Behavioral  descriptions  are  given  using  the  VHDL  language.  In  a  first 
sub-section  we  highlight  the  main  features  of  VHDL  behavioral  descriptions.  We 
describe  in  a  second  sub-section  how  these  features  have  been  represented  by  an 
efficient  graph  modeling  scheme. 

3.1  Main  features  of  VHDL  Behavioral  Descriptions 

Four  kinds  of  objects  are  involved  in  VHDL  behavioral  descriptions  : 

.  Constants  which  have  a  predefined  and  unchangeable  value. 

.  Variables  which  can  be  modified  by  an  assignement  statement. 

.  Signals  which  are  the  specificity  of  VHDL. 

.  Processes  which  are  the  fundamental  objects  manipulated  by  VHDL. 

Variables  are  local  to  processes  that  is  to  say  they  can  be  read  or  affected  only  in 
the  process  where  they  are  declared. 

Signals  are  global  to  the  overall  description  that  is  to  say  that  they  may  be 
common  to  several  processes. 

A  behavioral  description  leans  on  the  description  of  a  set  of  processes  where 
each  process  is  defined  using  a  procedural  description. 

The  key  statement  of  a  process  is  the  WAIT  statement, 
syntax  :  WAIT  {ON  signal -list}  {UNTIL  boolean-condition} 

This  statement  allows  to  suspend  a  process  execution,  that  will  restart  when  the 
next  condition  will  be  true  i  an  event  occurs  on  one  of  the  signals  specified  in  the 
signaljist  and  the  evaluation  result  of  the  boolean_condition  is  true. 

The  simulation  of  a  VHDL  description  is  composed  of  two  steps  :  an 
initialization  phase  and  an  execution  phase. 

The  initialization  phase  consists  in  determining  the  initial  value  of  each  signal 
according  to  the  following  rules : 

.  the  initial  value  is  given  explicitly  during  the  signal  declaration. 

.  the  initial  value  is  given  implicitly.  This  value  is  defined  like  being  the  first  of 
the  signal  definition  domain. 

With  these  initial  values,  each  process  of  the  description  is  executed  without 
looking  at  the  conditions  associated  with  Wait  statements. 

The  execution  phase  is  performed  by  scanning  of  the  sensitive  signals  and  is 

driven  by  the  events.  ,  .  ■ 

This  modeling  scheme  will  be  described  in  sub-section  2.2  using  the  behavioral 

description  given  in  Figure  1 . 
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Entity  Register  IS 

Port  (DI :  IN  vlbit_ld(l  TO  8) ; 

STRB,  DSl,  NDS2  ;  IN  vlbit ; 

DO  ;  OUT  vlbit_ld(l  TO  8)) ; 

END  Register 

Architecture  behavior  of  Register  IS 
SIGNAL  reg  :  vlbi_ld(l  TO  8); 

SIGNAL  enbld  ;  vlbit ; 

BEGIN 

strobe:  PROCESS  (STRB) 
begin 

If  (STRB  =1)  then  reg  <=  DI; 

End  If; 

END  PROCESS  Strobe; 

enable  :  PROCESS  (DSLNDS2) 
beign 

enlbd  <=  DSl  AND  NOT  (NDS2); 

END  PROCESS; 

output :  PROCESS  (reg, enbld) 

Begin 

If  (enbld=l)  then  DO<=reg 
Else  DO<=  11111111; 
end  If 

END  PROCESS; 

END  Behavior 

Figure  1  :  VHDL  behavioral  description 

3.2  Behavioral  Modeling 

This  sub-section  aims  at  describing  the  model  used  to  highlight  the  main 
features  of  VHDL  behavioral  descriptions.  In  order  to  facilitate  definition  of  formal 
methods  based  on  graph  structures  for  behavioral  fault  simulation,  we  have  been 
interested  in  the  development  of  two  models : 

.  the  input/output  model  allowing  to  represent  existing  links  between  signals  involved 
in  different  processes  of  a  description  [9].  This  model  has  been  defined  in  [9]  in  order 
to  perform  Test  Pattern  Generation. 

.  the  activation  model  pointing  out  the  the  execution  of  the  processes  involved  in  a 
VHDL  description.  This  model  is  based  on  a  model  developed  in  [9].  However  we  have 
improved  this  previous  model  by  defining  a  new  modeling  scheme  involving  pure  Petri 
Nets.  The  use  of  Petri  Nets  will  be  useful  when  a  behavioral  fault  simulation  algorithm 
will  be  defined. 
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The  VHDL  behavioral  description  activation  model  is  given  in  Figure  2.  We 
have  to  mention  that  the  activation  model  is  made  up  of  the  following  elements  :  a  data 
model,  a  control  model  and  their  explicit  interactions. 

The  Data  Model  represents  the  objects  (variables  and  signals)  pd  the  handled 
operations  involved  in  the  description.  It  is  composed  of  a  graph  involving  two  types  of 
nodes  :  data  nodes  and  operation  nodes. 

Let  us  point  out  that  the  data  nodes  have  not  been  represented  on  the  Figure  2. 

Operation  nodes  are  of  two  types ; 

.  assignment  nodes  which  represent  the  assignment  of  an  object  by  an 
algebraic  or  boolean  operation. 

.  decision  nodes  which  represent  an  algebraic  or  boolean  test  the  result  of 
which  is  taken  into  account  in  a  branch  in  the  Control  Model. 

The  Control  Model  represents  the  sequencing  of  the  operations  involved  in  the 
description.  It  is  based  on  a  Petri  Net  modeling. 

The  interaction  between  the  Control  Model  and  the  Data  Model  is  achieved  by 
associating  an  operation  node  to  a  place.  Two  links  are  involved  between  the  place  and 
the  operation  node  :  an  activation  link  of  the  operation  node  and  an  end  report  link. 

The  dynamical  aspect  of  the  interaction  of  the  two  models  is  supported  by 
tokens.  When  a  token  arrives  in  a  place,  the  associated  operation  is  performed.  In  case 
of  a  decision  node,  the  result  associated  with  the  end  report  link  is  used  in  order  to 
select  the  next  transition  to  fire.  In  Figure  4,  we  give  the  Petri  Net  associated  with  the 
description  given  in  Figure  1 . 


Figure  2  :  Activation  Model 
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4  Behavioral  Fault  Modeling 

A  fault  modeling  scheme  based  on  the  definition  presented  in  section  2  allows 
to  derive  a  set  of  fault  hypotheses  on  the  previously  described  model. 

Fault  hypotheses  are  defined  according  to  the  elements  involved  in  the  model  of 
the  circuit  under  test. 

A  General  Fault  Model  (G.F.M.)  can  be  generated  using  the  two  rules  presented 
in  section  1.  This  fault  Model  involves  all  possible  fault  hypotheses  defined  on  the 
basic  modeling  element  and  with  modification  of  the  model  structure. 

Because  of  the  too  large  number  of  faults  involved  in  this  model  we  may  have 
to  reduce  it. 

In  order  to  have  a  behavioral  fault  model  for  which  some  measures  of 
confidence  are  provided,  we  may  select  from  among  the  G.F.M.  some  fault  hypotheses 
according  to  the  fault  model  proposed  in  [10]. 

The  selected  fault  hypotheses  may  be  classified  as  follows  : 

1.  Stuck-at  fault  on  an  element  of  the  data  model : 

.  The  value  attribute  of  a  data  node  is  stuck-at  VI  or  V2  where  VI  and  V2 
express  the  lower  and  upper  extremes  of  the  domain  definition  of  the 
represented  signal  or  variable. 

.  The  output  of  an  operation  node  may  fail  such  that  it  permanently  returns 
VI  or  V2,  where  VI  and  V2  express  the  lower  and  upper  extremes  of  the 
range  of  the  operation. 

2.  Stuck-at  fault  of  an  element  of  the  control  model : 

.  a  control  transition  is  always  selected  whatever  the  resulting  value  set  up 
on  the  end  report  link  may  be 
.  a  process  is  never  active 
.  a  process  is  always  active 

3.  Stuck-at  fault  of  an  element  of  the  interaction  of  the  control  and  data  models  : 

.  when  a  token  arrives  in  a  place,  the  corresponding  operation  is  not 
performed.  This  means  that  the  activation  link  is  stuck-at  0. 

Depending  on  the  results  given  by  these  fault  hypotheses  in  terms  of  gate-level 
fault  coverage,  this  fault  model  can  obviously  be  extended.  However,  having  translated 
the  behavioral  fault  model  proposed  in  [10]  by  a  set  of  fault  hypotheses  on  the  basic 
elements  of  the  activation  model  defined  in  section  2,  the  quality  of  the  test  vectors 
generated  for  the  previous  fault  model  can  be  evaluated  by  the  results  presented  in  [10]. 

5  Current  and  Future  work 

Our  current  work  deals  with  behavioral  fault  simulation  [11].  Fault  simulation  is 
known  to  be  an  important  step  in  the  testing  of  digital  systems.  It  is  usually  used  to 
evaluate  the  fault  coverage  of  each  test  vector  generated  by  an  Automatic  Test  Pattern 
Generation  program.  Traditional  fault  simulation  algorithm  [12,  13,  14]]  are  not  able  to 
deal  with  behavioral  descriptions  and  behavioral  fault  hypotheses.  We  are  interested  in 
defining  new  algorithms  allowing  to  perform  fault  simulation  on  VHDL  behavioral 
descriptions. 

Given  a  test  sequence,  a  VHDL  description,  a  set  of  behavioral  fault  hypotheses, 
our  goal  is  to  deduce  the  list  of  behavioral  fault  hypothesis  detected  by  the  given  test 
sequence. 
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The  first  approach  we  have  investigated  is  to  define  an  algorithm  based  on  the 
deductive  fault  simulation  [12]. 

This  approach  consists  in  propagating  a  fault  list  through  the  basic  elements  of 
the  activation  model.  Given  a  test  sequence,  this  propagation  is  made  until  that  we  meet 
a  primary  output  is  reached.  To  evolve  this  method,  we  consider  the  activation  model 
as  an  interconnexion  of  four  kinds  of  basic  elements  shown  in  figure  3. 
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Figure  3b:  Assignment 
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Figure  3c:  Parallelism 
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Figure  3d:  Junction 


Figure  3  :  Basic  elements  involved  in  the  activation  model 

We  have  defined  how  lists  of  detected  faults  Loi  can  be  computed  according  to: 

-  each  kind  of  basic  elements. 

-  Lii,  lists  of  detected  faults  already  computed. 

-  a  given  test  pattern. 

Our  current  work  is  to  define  algorithms  allowing  to  propagate  a  fault  list 
through  each  basic  element. 

Our  future  work  will  investigate  the  definition  of  a  method  based  on  a 
concurrent  fault  simulation  [14]. 

References 


[1]  D.S.  Barcaly,  J.R.  Armstrong,  "A  chip-level  Test  Generation  Algorithm",  23th 
IEEE/ ACM  Design  Automation  Conf.  1986,  pp.257-261. 

[2]  U.H.  Levendel,  P.R.  Menon,  "Test  Generation  algorithms  for  computer 
hardware  description  languages",  IEEE  Transactions  on  Computers,  Vol.C-31, 
pp.577-588,  1982 

[3]  M.D.  Oneill,  D.D.  Jani,  C.H.  Cho,  J.R.  Armstrong,  "BTG  :  a  Behavioral  Test 
Generator",  9th  Computer  Hardware  Description  Languages  and  thier 
Application,  IFIP,  pp.347-361,  1990. 

[4]  F.E.  Norrod,  "An  automatic  test  generation  algorithm  for  hardware  description 
language",  26th  Design  Automation  Conference,  pp. 76-85,  July  1989. 

[5]  H.D.  Hummer,  H.  Veit,  H.  Toepfer,  "Functional  Tests  for  hardware  derived 
from  VHDL  description",  CHDL  91,  pp.  433-445,  1991. 

[6]  A.L.  Courbis,  J.F.  Santucci,  N.  Giambiasi,  "Automatic  Test  Pattern  Generation 
for  Digital  Circuits",  1st  Asian  Symposium,  Hiroshima,  pp.  1 12-118,  1992. 


7 


[7]  J.F.  Santucci,  A.L.  Courbis,  N.  Giambiasi,  "Behavioral  Testing  of  digital 
Circuits",  Journal  of  MicroelectronicSystmes  Integration,  Vol.l,  N°l„  March 
1993,pp.55-78. 

[8]  B.  Straube,  M.  Gulbins,  E.  Fordran,  "An  approach  to  Hierarchical  test 
Generation  at  Algorithmic  Level",  IEEE  Workshop  on  hierarchical  test 
Generation  ,  Blackburg,  Virginia,  USA,  8-11  august  93. 

[9]  V.  Pla,  J.F.  Santucci,  N.  Giambiasi,  "On  the  modeling  and  Testing  of  VHDL 
Behavioral  Descriptions  of  Sequential  Circuits,  3rd  IEEE  Euro-Dac/Euro- 
VHDL,  Hamburg,  September  93,  pp.440-445. 

[10]  S.  Ghosh,  T.J.  Chakraborty,  "On  behavior  fault  modeling  for  digital  designs". 
Journal  of  Electronic  Testing  :  Theory  and  Applications,  Vol.  2,  pp.  135-151, 
1991. 

[11]  D.  Federici,  J.F.  Santucci,  P.  Bisgambiglia,  "Behavioral  Fault  Modeling  and 
Simulation",  3rd  BELSIGN  Workshop  Proceedings,  11-12  April  96,  Porticcio, 
France. 

[12]  D.B.  Armstrong,  "A  Deductive  Method  for  Simulating  Fault  in  Logic  Circuits", 
IEEE  Trans,  on  Computers,  Vol  C-21,  N°5,  May  1972,  pp.  464-471. 

[13]  P.  Goel,  P.R.  Moorby,  "fault  Simulation  Techniques  for  VLSI  Circuits",  VLSI 
Design,  July  1984,  pp.22-26. 

[14]  E.G.  Ulrich,  T.Baker,  "The  Concurrent  Simulation  of  Nearly  Identical  Digital 
Networks",  Proc.  10th  Design  Automation  Workshop,  IEEE  and  ACM,  New 
York,  June  1973,  pp.  145-150. 


8 


Technical  Session  4 


Spatial  Applications 

Chair:  P.  David,  Matra  Marconi  Space,  France 


•  CATSATs  Soft  X-Ray  Detection  System:  An  Innovative  and  Cost  Effective  Approach, 

S.P.  Lynch,  Institute  For  the  Study  of  Earth,  Oceans  &  Space,  New  Hampshire,  USA 

•  Petri  Nets  for  a  Space  Operational  System  Availability  Study, 

M.  Saleman,  CNES  , 

J-F.  Ereau,  LAAS-CNRS,  France 

•  Results  of  Low-Cost  Propulsion  System  Research  for  Small  Satellite  Application, 

J.J.  Sellers,  T.J.  Laurence,  USAF,  Centre  for  Satellite  Eng.  Research,  Univ.  of  Surrey,  UK 
M.  Paul,  Surrey  Satellite  Technology  Limited,  Guildford,  UK 

•  Multiple  Technology  Choice  for  a  Mixed  Analog-Digital  Space  Radio-Astronomy 
Spectrometer, 

J.L.  Noullet,  LAAS-CNRS  Toulouse,  France 

L.  Ravera,  A.  Ferreira,  LESIA-INSAT  Toulouse,  France 
D.  Lagrange,  M.  Giard,  CESR-CNRS  Toulouse,  France 

M.  Torres,  IRAM-CNRS  Grenohle,  France 


CATSAT’s  Soft  X-Ray  Detection  System: 
An  Innovative  and  Cost  Effective  Approach 

Steve  P.  Lynch^ 


Small  Satellite  Laboratory 
Institute  for  the  Study  of  Earth,  Oceans  &  Space 
University  of  New  Hampshire 
Durham,  NH  03824,  USA 


ABSTRACT 

This  paper  describes  an  innovative  and  cost  effective  approach  to  detecting  low 
energy  x-ray  emissions  from  gamma-ray  bursts.  This  data  will  assist  scientists  in  solving 
the  important  problem  of  locating  the  source  of  these  bursts.  The  approach  makes  the  low 
energy  measurements  using  an  array  of  avalanche  photodiodes  (APDs).  APDs  are  a 
proven,  inexpensive  technology  that  will  enable  the  system  to  be  flown  aboard  a  small 
satellite,  CATSAT. 

1.  INTRODUCTION 

The  Cooperative  Astrophysics  and  Technology  Satellite  (CATSAT)  is  a  combined 
effort  between  three  universities  to  study  the  origin  of  cosmic  gamma  ray  bursts. 
Astrophysicists  have  speculated  for  years  as  to  how  far  away  the  bursts  occur,  but  to  date 
no  common  theory  is  agreed  upon.  In  a  unique  approach  to  solving  this  problem 
CATSAT  will  measure  low  energy  x-rays,  known  as  “Soft  X-Rays,”  emitted  from  the 
bursts  using  an  array  of  APDs,  and  use  this  data  to  calculate  how  far  away  the  bursts 
occurred.  The  APDs’  relative  noncomplexity  and  low  cost  enables  such  an  important 
scientific  contribution  to  be  made  using  a  small  satellite  mission. 

Supported  by  a  grant  from  NASA’s 
Student  Explorer  Demonstration  Initiative, 
(STEDI)  CATSAT  is  representative  of  the 
emerging  field  of  “small  satellites.”  [USR, 
94]  Small  satellites  are  typically  less  than 
600  kg  in  mass,  fly  in  a  low  earth  orbit  (550 
km)  and  have  a  design  time  of  two  years. 
Economic  constraint  is  the  driving  force 
behind  the  development  of  small  satellites, 
as  larger  missions  become  increasingly 
complex  and  expensive.  Student 
involvement  in  the  design  and 
manufacturing  processes  is  an  integral  part 
of  the  STEDI  program  and  students  from 
all  three  universities  are  playing  an  active 


Figure  1  CATSAT  Small  Satellite 
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role  as  CATSAT’s  design  engineers.  CATS  AT  is  currently  scheduled  to  be  launched  in 
July  of  1998. 

This  paper  focuses  on  the  Soft  X-Ray  (SXR)  detection  system  for  CATSAT, 
which  includes  the  APDs  and  their  associated  analog  and  digital  circuitry.  The  SXR 
system  is  contrasted  with  conventional  low  energy  x-ray  detection  systems,  which  would 
not  be  feasible  for  a  small  satellite  mission  due  to  their  cost  and  complexity. 

2.  CATSAT  ORGANIZATION 

The  CATSAT  team  is  comprised  of  three  universities,  the  University  of  New 
Hampshire  (UNH),  Weber  State  University  (WSU)  in  Utah  and  Leicester  University  (LU) 
in  England.  At  UNH,  the  mission  leader,  the  Institute  for  the  Study  of  Earth,  Oceans  and 
Space  (EOS)  is  collaborating  with  the  Electrical  and  Computer  Engineering  Department 
(ECE).  This  team  will  design  the  spacecraft’s  scientific  instrumentation  and  electronics. 
Much  of  the  design  work  is  being  carried  out  by  undergraduate  and  graduate  students  as 
per  STEDI  guidelines.  The  instrument  design  group  at  UNH  is  working  closely  with 
Leicester  University  in  England,  where  the  housing  for  the  SXR  detectors  will  be  built  and 
tested. 

The  Center  for  Aerospace  Technology  (CAST)  at  Weber  State  University  in  Utah, 
is  responsible  Tor  the  design  and  fabrication  of  the  spacecraft  frame.  WSU  is  also 
responsible  for  spacecraft  attitude  determination  and  control. 


3.  SOFT  X-RAY  DETECTION  SYSTEM 

3.1  Scientific  Basis 

Gamma-ray  bursts  (GRBs)  were  first  detected  in  the  early  seventies.  Vela 
satellites  accidentally  discovered  them  as  they  were  monitoring  Soviet  compliance  with  the 
Nuclear  Test  Ban  treaty.  [KLE,  73]  Since  that  time  astrophysicists  have  been  unable  to 
satisfactorily  explain  both  the  nature  and  the  origin  of  GRBs.  Current  theories  vary 
widely,  from  local  origins  to  galactic  and  even  extragalactic  origins.  It  is  generally 
accepted  that  the  bursts  are  caused  by  extremely  energetic  events  which  may  be  some  of 
the  most  spectacular  in  nature.  Studies  have  been  unsuccessful  in  trying  to  correlate  the 
-400  bursts  reported  per  year  with  events  at  different  wavelengths  or  other  astronomical 
objects.  It  was  hoped  that  counterparts  to  the  GRBs  would  provide  clues  as  to  their 
origin  using  searches  at  radio,  infra-red,  optical  and  x-ray  wavelengths.  [OWE,  94] 

CATSAT’s  innovative,  multi-observational  approach  will  give  scientists  the  first 
measurements  of  the  distance  to  gamma-ray  bursts,  solving  the  most  important  problem  in 
GRB  studies.  The  key  to  these  distance  measurements  lies  in  the  SXR  system’s  ability  to 

measure  low  energy  x-ray  data. 

' » 

3.2  SXR  Module 

The  SXR  module  is  located  on  the  top  of  the  satellite  where  it  obtains  a  field  of 
view  of  approximately  27C  steradians.  It  is  divided  into  7  independent  panels,  each  one 
containing  16  APDs,  providing  a  total  of  112  APDs.  The  module  housing  is  designed  to 
radiate  heat  and  maintain  the  temperature  of  the  APDs  at  -40  C,  ±5  degrees.  Protective 
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doors  cover  the  module  during  launch  and  are  opened  once  the  satellite  has  maintained  a 
stable  orbit. 

The  instrument  electronics  for  each  of  the  7  panels  amplifies  the  APD  signals, 
digitizes  the  data  and  temporarily  stores  it  in  memory.  The  data  is  systematically  retrieved 
from  the  panel  memory  by  the  instrument  CPU,  stored  in  the  main  memory  and 
downloaded  to  earth  every  twelve  hours.  The  in-flight  calibration  (IFC)  circuitry  for  each 
panel  will  maintain  the  APDs  at  stable  operating  conditions. 

I 

3.3  Avalanche  Photodiodes  (APDs) 

The  APD  is  ideal  for  low  energy  x-ray  detection  in  a  small  spacecraft.  It  is  a 
compact,  low  power  device  and  has  excellent  energy  resolution.  In-flight  calibration 
circuitry  will  individually  gain  adjust  each  APD.  This  stabilizes  the  operating 
characteristics  of  all  the  APDs  in  a  panel  for  example,  and  ensures  that  the  spectra 
collected  with  that  panel  will  appear  as  though  it  was  taken  with  one  large  device. 

The  APD  used  aboard  CATS  AT  is  a  silicon  device  with  a  thickness  of  about  2  mm 
and  a  detector  top  surface  area  of  1.69  cm^.  The  APD  cutaway  view,  shown  in  Figure  2, 
displays  the  p  diffusion  region  on  top,  the  multiplication  region  in  the  middle  and  the  n 
dififiision  region  on  the  bottom.  The  diagram  depicts  the  operation  of  the  APD,  whereby  a 
charged  particle  strikes  the  p-region  causing  an  avalanche  process  that  produces  a  current 
pulse  at  the  output. 

4.  ECONOMIC  CONSTRAINTS 

STEDI  funding  provides  a  total  of  4 
million  dollars  to  the  CATS  AT  project  for 
design  and  fabrication  of  the  entire  spacecraft 
and  its  payload.  This  is  modest  in  comparison 
to  the  cost  of  many  modem  spacecraft,  which 
can  be  100  times  more  expensive  and  even 
then  are  not  guaranteed  to  be  successful.  The 
cost  of  launching  “traditional”  satellites  can 
also  be  enormous.  NASA  and  other 
governmental  agencies  across  the  world  realize 
this  and  recent  years  have  seen  a  concerted 
preamp  effort  to  promote  small  satellite  design  as  a 
valuable  alternative  to  large  missions.  In  fact, 
it  is  a  specific  goal  of  the  STEDI  program,  which  was  initiated  by  NASA  and  the 
Universities  Space  Research  Association,  to  “demonstrate  that  small,  relatively  low-cost, 
and  rapidly  developed  space  missions  can  both  enrich  education  and  produce  significant 
science.”  [USR,  94] 

It  is  with  respect  to  these  economic  constraints  that  a  tremendous  advantage  of  the 
SXR  system  can  be  seen;  its  total  cost  is  a  fraction  of  that  of  conventional  methods  of  low 
energy  x-ray  detection.  Without  this  new  application  of  APDs  in  the  SXR  system  it  is 
doubtful  that  CATSAT  would  be  able  to  complete  its  mission  given  the  limited  budget. 
Because  of  the  relatively  low  cost  of  the  APDs  (approximately  $1,000  each)  the  complete 
array  for  the  SXR  system  can  be  built  for  just  over  SIOOK.  The  electronics,  which 


Figure  2  Avalanche  Photodiode 
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includes  low  noise  “hybrid”  devices,  is  estimated  to  cost  between  $50K  and  $60K,  and  the 
housing  can  be  built  for  under  $10K.  This  allows  the  complete  system  to  be  built  for 
around  $200K. 

Table  1  below  shows  a  comparison  of  the  estimated  cost  of  the  SXR  system 
compared  to  other  methods  that  could  be  used.  Note  that  the  estimates  are  based  on  a 
system  that  would  have  a  comparable  field  of  view  to  the  SXR  system. 

5.  SYSTEM  COMPLEXITY 

System  complexity  is  an  important 
factor  in  a  small  satellite  mission.  The  two  year 
design  and  construction  period  along  with  the 
limited  payload  capabilities  of  a  small  spacecraft 
would  make  it  difficult  to  use  the  conventional 
methods  mentioned  in  Table  1.  Low  energy 
photon  spectrometers  for  example,  operate  at  extremely  low  temperatures,  requiring  the 
storage  of  liquid  nitrogen  onboard  the  spacecraft.  The  surface  area  of  the  detectors  is  also 
very  small,  approximately  10  mm  square,  which  would  require  the  use  of  a  large  number 
of  them  to  obtain  a  sufficient  field  of  view.  Charge  Coupled  Devices  (CCDs)  are  also 
impractical  as  they  have  a  “dead  time”  that  would  severely  hinder  the  ability  of  the 
instrument  to  record  bursts. 

While  the  SXR  system  does  require  precise  control  of  the  APDs,  it  is  still  less 
complicated  in  comparison  to  the  above  methods.  The  system  incorporates  passive 
environmental  control  and  also  has  built  in  redundancy  due  to  the  large  number  of 
detectors. 

6.  CONCLUSION 

This  paper  has  described  an  innovative  approach  to  solving  a  problem  that  has  long 
been  debated  by  the  astrophysics  community:  the  origin  of  gamma-ray  bursts. 
Furthermore,  the  SXR  detection  system  demonstrates  that  spacecraft  technology  can  be 
developed  at  low  cost  and  in  a  short  time  frame.  The  CATSAT  mission  has  found  a  new 
use  for  an  existing  technology,  and  incorporated  it  in  a  small  satellite  program  for  a 
fraction  of  the  cost  of  conventional  systems. 

The  reiktive  noncomplexity  of  the  SXR  system  has  allowed  undergraduate  and 
graduate  engineering  students  to  work  on  a  real-life  design  effort  and  gain  valuable 
experience.  If  successfiil,  CATSAT  will  be  a  powerful  incentive  for  “smaller,  faster  and 
cheaper”  missions  that  can  provide  important  contributions  to  the  scientific  community. 
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Table  1  Cost  Comparisons 


System 

Cost  ($) 

Soft  X-Ray  System 

200K 

Low  Energy  Photon 
Spectrometers  [ORT,  95] 

5M 

Charge  Coupled  Device 

IM 
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ABSTRACT 

This  paper  presents  an  availability  study  of  a  space  operational  system  called  TPFO 
(Topex  Poseidon  Follow  On)  using  Petri  nets  for  both  modeling  and  evaluation  aspects. 
The  aim  of  this  study  was  to  examine  mission/system  trades  that  might  be  possible  in 
view  of  TPFO  missions  with  the  intent  of  achieving  minimum  program  cost.  Thus,  the 
study  have  to  take  into  account  several  aspects  of  the  program,  as  mission  time,  number 
of  satellites,  satellite  reliability  and  lifetime,  satellite  production  and  storage  policies, 
launch  reliability  and  availability,  relaunch  policy,  etc...  and  to  identify  options  for 
achieving  availability  objectives  with  minimum  total  cost.  We  illustrate  in  this  paper  Petri 
net’s  ability  to  deal  with  such  system  from  both  modeling  and  evaluation  view  points. 
The  results  obtained  by  this  method  provide  interesting  outputs  for  the  project.  This  is 
shown  through  the  interpretation  of  typical  results. 

1.  INTRODUCTION 

Today  space  projects  are  far  from  their  initial  experimental  feature  and  in  many 
application  areas,  such  as  communication,  localization  or  observation,  these  systems  have 
to  deal  with  operational  constraints  and  minimum  program  cost. 

Among  the  various  system  analyses  performed  during  the  early  design  phases  of 
projects,  availability  analysis  provides  important  results  for  system  dimensioning. 
Actually,  they  help  to  select  maintenance  strategies  and  associated  resources,  to  satisfy 
availability  objectives  with  minimum  or  reduced  global  cost. 

Considering,  the  modelisation  view  points  of  such  systems  availability  are  confronted 
with  several  constraints  like  sequential  processes  as  satellites  productions,  parallel 
processes  as  satellite  productions  and  launch  requests,  synchronized  processes  as  launch 
campaign  needed  a  satellite  and  a  launcher  available.  In  addition,  different  time 
characteristics  have  to  be  taken  into  account;  deterministic  ones  like  satellite  production 
time  or  satellite  lifetime,  and  stochastic  ones  like  satellite  time  to  failure. 
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Petri  nets  are  well  adapted  to  support  a  structured  approach  because  they  are  based  on 
a  system  view  under  the  form  of  a  set  of  sequential  processes  or  active  objects  which  are 
interacting.  This  is  the  reason  they  offer  an  easy  understanding  of  the  system  behavior 
which  can  improve  the  dialog  between  the  analyst  and  the  project  team.  In  addition,  the 
Stochastic  and  Time  Petri  Net  (STPN)  (Ref  1),  which  is  an  extended  model  of 
Generalized  Stochastic  Petri  Net  (GSPN)  (Ref  2),  is  able  to  deal  with  arbitrary  time 
distribution  like  exponential,  deterministic  or  uniform.  Hence,  performance  parameters, 
like  availability,  in  the  transient  and  stationary  periods  can  be  estimated  by  the  simulation 
of  the  nets. 

The  aim  of  this  paper  is  twofold;  through  an  example  of  a  satellite  system,  we  illustrate 
Petri  Net  ability  for  modeling  and  evaluation  of  such  systems,  and  thanks  to 
interpretation  of  typical  results,  we  stress  how  such  availability  studies  can  be  useful  for 
project  management. 

Section  2  presents  the  system  example  to  be  studied.  Input  parameters  over  which 
sensitivity  analysis  can  be  performed  are  defined. 

Section  3  presents  the  Petri  Net  models  built  to  represent  this  system.  We  focus  here  on 
the  description  of  the  logical  behavior  of  the  system,  hence  the  time  parameter  is  not 
explicitly  taken  into  account. 

Section  4  justifies  the  choice  of  the  time  extension  of  the  Petri  Net  used:  the  Stochastic 
and  Time  Petri  Nets.  We  present  the  principle  of  the  net  simulation  and,  for  a  specific 
value  of  the  defined  input  parameters,  we  provide  and  comment  on  typical  results. 

Section  5  emphasizes  the  usefulness  of  such  a  flexible  approach  from  both  the  analyst 
and  the  project  manager  view  points. 

2.  SYSTEM  DESCRIPTION 

The  system  is  described  by  its  input  parameters  and  its  logistic  support  policy. 

2.1  Input  parameters 

The  system  studied  is  composed  by  (see  figure  1); 

•  the  space  segment,  and 

•  the  ground  logistic  support  segment,  i.e.  all  the  resources  needed  to  set  up  and 
maintain  the  space  segment 

The  space  segment  is  based  on  a  Low  Earth  Orbit  (LEO)  satellite 

The  ground  logistic  support  includes  the  following  resources: 

•  a  satellite  production  line, 

•  the  possibility  of  a  stock  capacity 

•  a  launching  area 
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LOGISTIC  SUPPORT  SEGMENT  ;  ground  resources 
Figure  1.  System  components 


Table  1  provides  the  stochastic  and  time  input  parameters  for  with  both  space  and 
logistic  support  segments. 

The  failure  rates  for  nominal  satellite  is  supposed  to  be  constant,  so  satellite  reliability  is 
exponentially  distributed. 

The  values  of  these  input  parameters  come  from  historical  technical  characteristics  of 
space  vehicles,  launchers,  and  production  systems. 


Parameter 

Comments 

SPACE  SEGMENT  1 

Satellite  failure  rate 

Ti,i,(scil) 

Time  to  satellite  end  of  life 

Time  injection  and  test  a  satellite 

Ptiiieciioii 

Probability  of  injection  success 

LOGISTIC  SUPPORT  SEGMENT  I 

T,.rod(sal) 

Time  to  produce  a  satellite 

Time  to  have  a  launcher  available 

Time  of  the  launch  campaign 

Pliiiiiich 

Probability  of  launch  success 

Table  1.  Time  and  stochastic  input  parameters 
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2.2  Initialization  and  Maintenance  policy 

Initially,  a  satellite  is  produced  and  a  launcher  is  ordered.  As  soon  as  a  launcher  and  a 
satellite  are  available  and  the  campaign  is  done,  the  satellite  is  launched. 

If  the  launch  fails  or  the  injection  is  not  successful,  a  request  of  a  satellite  and  1 
launcher  is  made  and  a  new  launch  is  programmed  as  soon  as  possible. 

If  the  launch  and  the  injection  are  successful,  the  satellite  is  operational  on  orbit  until 
his  failure  or  end  of  his  lifetime.  Before  the  end  of  life  of  the  operational  satellite  in  orbit, 
a  satellite  production  and  a  launcher  request  are  programmed  to  have  them  available  to 
replace  it  with  no  interruption  of  the  mission. 

If  the  satellite  fails  before  the  programmed  date  to  ordered  it,  a  satellite  production  and 
a  launcher  request  are  ordered  to  replace  the  failed  satellite  as  soon  as  possible. 

This  maintenance  policy  assumes  that  satellite  and  launcher  productions  are  not 
planified  but  driven  by  the  space  segment  needs. 

In  case  of  possibility  of  satellite  stocking,  a  satellite  production  is  ordered  as  soon  as 
the  previous  satellite  is  launched. 

3.  MODEL  SPECIFICATION 

This  section  describes  the  models  designed  for  the  above  presented  system.  The  time 
parameter  is  not  taken  into  account  here,  we  only  stress  the  logical  behavior. 

.As  we  showed  in  section  2,  the  system  could  be  split  into  two  parts:  the  space  segment 
and  the  ground  logistic  support  segment.  The  global  Petri  net  of  figure  3  follows  this 
decomposition. 

The  sub-model  describing  the  behavior  of  the  space  segment.  The  associated  models  is 
presented  in  sections  3.2. 

The  ground  logistic  support  sub-model  describes  the  management  of  the  production 
and  launch  campaign  processes.  They  are  executed  in  sequence. 

Communication  between  these  two  sub-models  is  based  on  place  sharing.  Production 
requests,  if  marked,  allows  the  start  of  the  production  of  a  satellite  and,  concurrently, 
the  order  of  a  launcher.  Launch  requests,  if  marked  and  if  a  satellite  and  a  launcher  are 
available,  allows  the  launch  of  a  satellite.  If  this  launch  fails  {Failure  transition),  a 
production  is  automatically  ordered  and  another  launch  request  is  sent. 

If  launch  succeeds,  a  token  is  put  in  Launch  indication  which  indicates  that  a  satellite 
is  available  on  orbit.  This  communication  is  shown  in  figure  2. 


Satellite  Production  Requests 

r 

R  !  •:  .S  .S  O  U  R  C  E 

Satellite  Launch  Requests 

SPACE 

1'  R  O  c  ;  E  s  .s 

S  E  G  M  ENT 

L 

Satellite  Launch  Indications 

Figure  2.  Communication  between  space  segment  and  ground  resources 
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Figure  3.  Global  model 

Production  and  launch  processes  are  only  represented  here  as  transitions  {Production 
Process  and  Launch  Campaigti  transitions),  but,  they  could  be  complex  processes. 

Initially  no  satellite  has  been  produced,  launched,  or  deployed  so  the  initial  marking  is 
such  that  a  satellite  production  and  a  launcher  are  required. 

4.  MODEL  EVALUATION 

4.1  The  choice  of  Stochastic  and  Time  Petri  Net  simulation 

Ordinai-y  Petri  nets  are  an  asynchronous  model  into  which  time  is  not  explicitly 
incorporated.  A  transition  fires  from  the  moment  it  has  been  validated,  but  no  hypothesis 
has  been  made  as  to  the  firing  time.  These  models  cannot  be  used  for  quantitative 
analyses,  and  it  is  thus  necessary  to  describe  a  way  in  which  time  may  be  precisely 
represented. 

Several  temporal  extensions  of  the  basic  model  have  been  developed,  associating  time 
with  the  net  places,  arcs  or  transitions.  A  highly  general  extension  was  proposed  in 
(Ref  3),  based  on  the  association  of  time  intervals  with  transitions.  An  interval  is 
referenced  in  relation  to  a  transition  validation  date,  and  characterizes  the  set  of  possible 
dates  for  firing  this  transition.  The  Petri  net  can  thus  be  seen  as  a  set  of  temporal 
constraints,  coordinated  by  the  net  structure,  and  conditioning  the  net  change  over 
time. However,  tliis  concept  of  time  intervals,  as  associated  with  transitions,  is  not 
sutficient.  It  is  advisable,  in  fact,  to  specify  the  probability  of  the  transition  firing  within  a 
given  temporal  window.  To  this  end,  distribution  functions  are  associated  with  these  time 
intervals,  thus  characterizing  the  random  variable  for  "transition  firing  time".  This  is  the 
principle  on  which  Stochastic  Timed  Petri  Net  (Ref  2)  is  based. 

In  the  case  where  the  time  interval  is  [0,  oo[  and  the  only  possible  distribution 
associated  with  a  transition  is  the  exponential  distribution,  the  model  in  question  is  that 
of  Markovian  Stochastic  Petri  Nets  (Ref  4).  The  change  of  net  marking  over  time  is  thus 
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characterized  by  a  Markov  process.  Finally,  if  we  allow,  in  addition,  immediate  Dirac 
functions,  the  model  obtained  is  that  of  GSPN  (Ref  1)  which  thus  allows  for 
synchronizations  to  be  made. 

While  evaluation  methods  based  on  graph  generation,  like  Markov  graph  (Ref  1),  or 
probabilized  state  graph  (Ref  2)  are  effective  because  they  are  formal  and  analytic,  in 
our  specific  case,  Markov  graphs  don't  enable  the  inclusion  of  all  types  of  temporization, 
while  probabilized  state  graphs  supplies  only  the  mean  values  without  their  associated 
standard  deviations,  which  is  a  significant  restriction. 

Thus  the  Monte-Carlo  simulation  of  STPN  is  used  to  provide  results  in  both  the 
transient  and  stationary  periods.  The  simulation  is  based  on  multiple  random  evolution  of 
nets  conditioned  by  the  time  intervals  and  associated  distribution  functions  over  a  given 
observation  period. 

The  results  of  the  various  simulations  are  averaged  and  it  thus  becomes  possible  to 
obtain  the  mean  period  of  sojourn  time  in  the  various  markings,  the  average  number  of 
transition  f  rings,  etc. 

It  is  then  easy  to  deduce  the  dependability  magnitudes  in  which  we  are  interested. 

The  simulation  tool  used  for  such  system  evaluations  is  MISS-RdP  (Interactive 
Modeling  and  System  Simulation  using  Petri  Nets)  (Ref  5)  which  has  been  developed  by 
IXI  corp.  in  a  partnership  which  includes  academic  research  (CNRS-LAAS),  industrial 
companies  (aeronautics,  space  and  nuclear  companies)  and  the  French  Space  Agency 
(CNES).  It  supports  STPN  model  simulation  and  provides  results  in  standard 
spreadsheet  formats.  The  collaboration  still  goes  on  and  a  new  version  for  colored  STPN 
is  developed  and  is  in  evolution  to  integrate  partners  needs. 

4.2  Simulation  parameters 

The  space  system  have  been  modeled  by  Petri  nets  in  a  symbolic  way.  Hence,  a  very 
wide  sensitivity  analysis  over  input  parameters  is  allowed  without  designing  new  models. 
We  do  not  proceed  it,  but  illustrate  over  examples  the  results  we  can  expect  and  how 
they  are  interesting  to  analyze  and  set  up  the  system. 

4.3  Results 

In  order  to  identify  that  might  achieve  the  mission  availability  objectives  under  the 
program  cost  constraints,  the  study  should  provide  for  the  entire  mission  : 

•  The  instantaneous  availability  during  mission  time 

•  The  mean  availability  over  the  mission  time 

•  The  satellite  reliability  and  lifetime 

•  The  satellite  production  and  stock  policy 

•  The  satellite  cumulated  storage  time 

•  The  number  of  satellites  launched 

•  The  number  of  unsuccessful  launches 

•  .  .  . 

Most  of  those  outputs  are  used  to  evaluate  the  total  cost  of  recurrent  program. 
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Other  interesting  outputs  for  the  project  are  provided  as  the  mean  number  of  satellites 
which  could  reach  half  of  the  lifetime  or  the  lifetime,.... 

INSTANTANEOUS  AVAILABILITY  FOR  SCENARIO  1 


I 


Figure  4.  Space  segment  instantaneous  availability 
Figure  4  displays  the  space  segment  availability  for  a  nominal  mission.. 

The  calculus  of  confidence  interval  comes  from  direct  application  of  central  limit 
theorem  to  the  random  availability  variable  (Ref  6).  Figure  6  shows,  for  10  000 
simulations,  the  confidence  curves  between  which  95  %  of  experimental  values  of 
nominal  mission  availability  should  be  located.  The  availability  results  are  accurate 
enough  to  allow  correct  interpretations. 


Figure  5.  Confidence  curves  of  nominal  mission  availability  at  95% 
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In  order  to  evaluate  the  mission  needs,  it  is  interesting  to  display,  at  a  specific  mission 
date,  the  number  of  satellites  and  launchers  required  and  the  associated  probabilities. 

Figures  6  displays  the  number  of  satellites  ordered  at  14  year^  and  the  associated 
probabilities.  For  example,  there  is  a  probability  of  about  0,8  that  5  satellites  or  less,  and 
a  probability  of  0,37  that  5  satellites  exactly,  have  been  launched  during  the  first  mission 
time:  [0,  14  years]. 


DISTRIBUTION  OF  THE  NUMBER  OF  SATELLITES  LAUNCHED 
AT  1  4  YEARS  (CASE  1  _1 ) 


•*567 
Number  of  satellites  launched 


Figure  6.  Number  of  satellites  ordered  at  14  years  and  associated  probabilities 

These  are  important  inputs  for  costs  &  risks  analysis  which  underline  the  necessity  to 
predict  launches  and  satellites  failures.  Moreover  it  helps  to  predict  and  plan  the 
productions. 

Costs  evaluations  are  not  presented  here  but  the  estimations  were  done  in  each  case 
studied.  The  part  of  each  partner  of  the  program  (launcher,  satellite  designer,..)  and  the 
total  cost  were  evaluated  to  compare  the  different  options 

5.  CONCLUSION 

This  paper  has  presented  the  approach  for  availability  evaluation  of  space  systems 
developed  in  the  French  Space  Agency.  It  has  been  led  in  other  various  cases  to  analyze 
commercial  or  scientific  space  projects  like  BIMILSAT  (communication),  TAOS 
STARS YS  (localization). 

From  the  analyst's  view  point,  Petri  net  modeling  and  simulation  of  such  systems,  while 
it  requires  a  non  negligible  effort  of  learning  and  training,  allows  us  to  surmount  the 
limitations  ot  traditional  approaches.  The  easy  to  understand  graphical  representation  of 
Petri  nets  improves  the  dialog  between  project  protagonists  who  can  share  the  same 
system  view  in  an  unambiguous  way.  Moreover,  Petri  net  modeling  is  flexible  enough  to 
allow  wide  sensitivity  analyses  without  designing  each  time  new  models. 


9 


Results  of  such  studies  overcome  the  simple  verification  of  availability  objectives. 
Actually,  they  help  to  define  optimal  deployment  and  maintenance  strategies.  Then, 
guidelines  can  be  provided  to  project  management  in  order  to  plan  satellite  production, 
negotiate  with  launcher  companies,  and  estimate  global  costs. 
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ABSTRACT — The  paper  summarizes  on-going  research  into  low-cost  propulsion 
system  options  for  small  satellite  attitude  and  orbit  control.  Research  into  the 
primary  cost  drivers  for  propulsion  systems  is  discussed  along  with  implications 
for  practical,  cost-effective  designs.  Results  of  hybrid  rocket  experiments  are 
highlighted.  Applications  for  this  technology  on  future  low-cost  missions  is 
examined.  Other  technology  options  are  also  reviewed  including  cold-gas 
thrusters,  resistojets  and  low-thrust  bi-propellant  engines.  The  propulsion  system 
for  the  forthcoming  UoSAT-12  minisatellite  system  is  described  in  detail  along 
with  on-orbit  capability  and  operational  modes.  Future  propulsion  research  work 
is  summarized. 

1.  INTRODUCTION 

The  current  catch-phrase  of  the  aerospace  industry — "faster,  better,  cheaper" — ^represents  political 
and  economic  necessity  as  much  as  good  engineering  practice.  While  industry  as  a  whole  struggles 
to  fully  define  this  "new"  strategy  in  the  wake  of  the  post-cold  war  draw  down,  the  University  of 
Surrey  and  its  commercial  arm  Surrey  Satellite  Technology  Ltd.  (SSTL),  as  well  as  others  in  the  so- 
called  “amateur”  satellite  community,  have  been  quietly  implementing  this  philosophy  all  along. 
Since  1981,  University  of  Surrey  satellites  (UoSATs)  have  shown  that  small,  reliable  satellites  can 
be  built  and  operated  at  costs  far  less  than  one  would  find  in  the  mainstream  aerospace  industry. 
The  basic  UoSAT  design,  evolved  over  more  than  ten  missions,  has  proven  itself  as  a  reliable  cost- 
effective  platform  for  quick  access  to  low  Earth  orbit.  So  far,  all  UoSAT  spacecraft  have  been  in  the 
microsatellite  range  (~  50  kg),  designed  to  operate  in  the  relatively  benign  environment  of  low- 
Earth  orbit  (LEO).  As  of  this  writing,  the  SSTL/UoSAT  team  have  logged  nearly  50  orbit-years  of 
operational  experience. 

The  success  of  small  satellite  missions  depends  on  low-cost  launch  opportunities.  So  far,  the 
majority  of  UoSAT  missions  have  been  on  Ariane  launchers  attached  to  the  Ariane  Structure  for 
Secondary  Payloads  (ASAP)  ring  and  deployed  into  LEO.  However,  a  review  of  Ariane  launch 
manifests  into  the  foreseeable  future  at  the  outset  of  our  research  revealed  the  majority  of 
opportunities  for  secondary  payloads  would  be  into  geosynchronous  transfer  orbit  (GTO).  This  is  a 
highly  elliptical  orbit  200  x  36,000  km  altitude  with  an  inclination  of  7°.  GTO  offers  a  variety  of 
mission  opportunities.  OSCAR  Phase-3  missions,  for  example,  have  used  GTO  as  starting  point  for 
Molniya  communications  missions.  Other  mission  opportunities  that  could  exploit  low-cost 
launches  into  GTO  include; 

•  Small  geosynchronous  (GEO)  communications — Currently,  developing  countries  must 
lease  transponders  on  large,  expensive  commercial  satellites.  The  possibility  exists  for  them 
to  purchase  their  own  small,  dedicated  satellite  at  a  competitive  price. 
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•  Meteorological  monitoring — Microsatellites  have  demonstrated  their  utility  for  localised 
weather  monitoring  from  LEO.  Small  satellites  beginning  in  GTO  could  be  used  as  low-cost 
weather  monitoring  platforms  with  the  higher  altitude  providing  more  global  access. 

•  Geomagnetic  data  collection — Because  spacecraft  in  GTO  travel  though  the  entire  depth  of 
the  Van  Allen  radiation  belts  twice  daily,  they  offer  a  unique  vantage  point  from  which  to 
monitor  important  phenomena  in  the  space  environment  such  as  solar  wind  and  magnetic  field 
interactions,  galactic  cosmic  rays  and  solar  flares. 

•  Ground-based  astronomy  calibration — Ground-based  optical  astronomy  is  handicapped  by 
the  dynamic  nature  of  Earth’s  atmosphere  which  attenuates  faint  signals.  A  satellite  in  very 
high  Earth  orbit  with  a  low-power  laser  of  known  wavelength  could  provide  the  feedback 
necessary  to  perform  real-time  calibration  and  correction  of  these  signals,  greatly  enhancing 
their  resolution. 

•  Lunar  and  planetary  exploration — From  GTO,  the  total  velocity  change  (AV)  necessary  to 
go  to  lunar  orbit.  Earth  approaching  asteroids  or  even  other  planets  is  roughly  equivalent  to 
that  needed  to  go  into  GEO.  Spacecraft  such  as  the  U.S.  Clemetine  mission  have 
demonstrated  how  very  good  planetary  science  can  be  conducted  from  small,  relatively  low- 
cost  (~$70M)  platforms.  The  opportunity  exists  to  use  GTO  as  a  springboard  to  explore  the 
solar  system  with  even  smaller,  and  far  cheaper  (~$10M)  satellites. 

In  addition  to  these  missions  specifically  related  to  GTO,  other  exciting  opportunities  are  emerging 
for  LEO  small  satellites: 

•  Micro-LEO  constellations — Constellations  of  two  or  more  store-and-forward 
communication  satellites  to  support  world-wide  paging,  data  collection  from  geographically 
remote  scientific  or  industrial  facilities,  disaster  relief  and  other  services. 

•  “Personal”  Remote  Sensing — ^Developing  coimtries  currently  depend  on  large,  expensive 
remote  sensing  platforms  such  as  SPOT  or  LANDSAT.  A  dedicated  small  satellite  with 
nearly  the  same  resolution  that  also  offers  on-demand  coverage  and  the  ability  for  the  user  to 
exercise  far  greater  control  over  imaging  times,  targets,  lighting  and  area  re-visits  appears 
feasible  at  a  competitive  cost. 

•  SAR  missions — Synthetic  aperture  radar  (SAR)  offers  the  ability  to  pierce  through  cloud 
cover  to  collect  images  day  or  night.  So  far,  this  technology  has  been  limited  to  very  large, 
expensive  platforms,  however,  it  now  appears  feasible  to  deploy  a  limited  but  useful  SAR 
capability  on  a  small  LEO  satellite. 

•  Equatorial  belt  missions — All  of  the  LEO  missions  listed  above  would  provide  global 
coverage  from  a  polar  orbit.  However,  developing  counties,  especially  in  the  Pacific  Rim 
such  as  Indonesia,  Malaysia,  Singapore  and  the  Philippines  are  increasingly  interested  in 
dedicated  regional  coverage.  This  could  best  be  provided  by  satellites  operating  in  very  low 
inclination  orbits. 

Unfortunately,  until  recently  UoSAT  spacecraft  (as  well  as  similar  satellites  built  by  other 
Universities  and  companies)  lacked  one  critical  system  that  would  allow  them  to  exploit  fully  the 
mission  opportunities  outlined  above:  a  propulsion  system.  Propulsion  systems  are  a  common 
feature  on  virtually  all  larger  satellites.  However,  until  now  there  has  been  no  need  for  very  small, 
low-cost  satellites  to  have  these  potentially  costly  systems.  As  secondary  payloads,  they  were 
deployed  into  stable,  useful  orbits  and  natural  orbit  perturbations  (drag,  J2,  etc.)  were  acceptable 
within  the  context  of  the  relatively  modest  mission  objectives.  Over  the  years,  these  pioneering 
small  satellite  missions  have  proven  that  effective  communication,  remote  sensing  and  space 
science  can  be  done  from  a  cost-effective  platform.  As  these  missions  have  evolved,  various 
technical  challenges  in  on-board  data  handling,  low-power  communication,  autonomous  operations 
and  low-cost  engineering  have  been  met  and  solved.  Now,  as  mission  planners  look  beyond  passive 
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missions  in  LEO  to  the  bold,  new  missions  described  above,  all  of  which  require  active  orbit  and 
attitude  control,  a  new  challenge  is  faced — cost-effective  propulsion. 

Propulsion  systems  are  needed  to  perform  a  variety  of  tasks  essential  to  active  missions  in  LEO  and 
beyond.  These  include: 

•  Orbit  Manoeuvring — the  ability  to  move  from  an  initial  parking  orbit  to  an  escape 
trajectory  or  insert  into  a  final  mission  orbit,  e.g.  changing  from  GTO  to  GEO. 

•  Orbit  Maintenance — the  ability  to  maintain  a  specific  orbit  against  drag  and  other 
perturbations,  or  phase  the  orbit  to  maintain  proper  angular  separation  of  a  constellation. 

•  Attitude  Control — The  ability  to  rotate  the  spacecraft  to  reorient  sensors  or  dump 
momentum,  especially  beyond  LEO  where  magnetorquing  and  gravity  gradient  stabilisation 
are  not  viable  options. 

Obviously,  all  these  capabilities  can  be  found  in  off-the-shelf  systems  used  throughout  the 
aerospace  community.  However,  current  off-the-shelf  technology  may  not  be  appropriate  for  cost- 
effective  applications  within  the  context  of  small  satellite  missions.  Furthermore,  the  cost  of  these 
systems,  when  procured  using  standard  aerospace  practices  can  be  prohibitive.  Thus,  small  satellite 
mission  planners  face  a  dilemma — future  missions  demand  a  propulsion  capability  but  the  cost  of 
this  single  system  may  be  prohibitive,  keeping  the  entire  mission  grounded. 

The  objective  of  the  research  described  in  this  paper  is  to  investigate  cost-effective  propulsion 
system  options  for  small  satellite  application.  The  following  discussion  will  address  a  new 
paradigm  developed  for  understanding  propulsion  system  costs  and  an  innovative  technique  for 
parametrically  combining  the  various  dimensions  of  this  paradigm  to  quantify  a  figure  of  merit  for 
specific  system  options  and  mission  scenarios.  This  technique  provides  a  useful  tool  for  mission 
and  research  planning  as  well  as  total  quality  management.  From  this  discussion,  hybrid  rockets 
and  water  resistojets  emerge  as  promising  technology  options  in  need  of  further  research.  Research 
programs  investigating  these  technologies  at  the  University  of  Surrey  will  be  described  along  with 
preliminary  results.  Finally,  the  near  term  application  for  this  propulsion  research  will  be  addressed 
by  describing  the  system  to  be  deployed  on  the  forthcoming  UoSAT-12  minisatellite  mission. 

2.  DISCUSSION 

2.1  Cost  Paradigm 

At  the  outset  of  the  research  into  the  cost  issues  of  propulsion  systems,  it  immediately  became 
obvious  that  the  broader  issues  of  spacecraft  hardware  costs  in  general  must  first  be  addressed 
before  propulsion  system  costs  specifically  could  be  fully  understood.  By  first  isolating  and 
explaining  the  fundamental  cost  drivers  of  these  traditionally  expensive  components,  a  credible 
strategy  could  be  formulated  for  reducing  the  costs  of  propulsion  hardware  specifically.  To  that  end, 
specific  spacecraft  hardware  cost  drivers  which  occur  during  each  phase  of  a  mission  were 
identified.  These  mission  phases  are: 

1.  Mission  Definition 

2.  Mission  Design 

3.  Hardware  Acquisition 

The  purpose  was  to  provide  a  useful  context  for  understanding  the  process  of  selecting  and  flying 
space  hardware  in  general  which  could  then  be  applied  to  propulsion  systems.  The  results  of  this 
effort  are  published  in  a  dedicated  chapter  of  Reducing  Space  Mission  Costs  edited  by  Dr.  Jim 
Wertz  [Wertz  96]. 

From  this  research,  a  new  paradigm  for  understanding  total  propulsion  system  cost  emerged. 
Traditionally,  the  approach  taken  to  describe  propulsion  cost  has  been  to  isolate  a  single  descriptive 
parameter  of  the  technology,  one  that  determines  what  was  perceived  to  be  the  most  important 
premium  on  a  satellite — ^mass.  The  propellant  mass  used  by  a  given  system  is  determined  by  its 
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specific  impulse,  Isp.  Specific  impulse  is  similar  in  concept  to  the  “miles  per  gallon”  rating  used  to 
compare  automobile  fuel  efficiency.  However,  while  mass  is  certainly  one  important  descriptive 
dimension  of  system  cost  it  is  not  the  only  one.  In  fact,  the  evidence  presented  from  [Dean  91] 
clearly  indicates  that  by  focusing  solely  on  mass,  true  cost  reduction  may  not  be  achieved.  It  is  even 
possible  that  the  overall  cost  is  increased  due  to  the  increased  system  complexity  needed  to  achieve 
the  higher  mass  efficiency. 

If  mass  is  not  the  only  dimension,  what  else  is  there  to  consider?  The  most  obvious  that  springs  to 
mind  is  the  bottom  line  price  paid  for  the  hardware.  In  some  situations,  price  can  be  the  most 
important  dimension,  especially  for  low-budget  missions  such  as  those  flown  by  small,  University- 
sponsored  satellites.  For  these  missions,  if  the  price  exceeds  a  certain  threshold  limit,  the  mission 
simply  will  not  get  off  the  ground. 

But  focusing  too  closely  price  alone  may  cause  you  to  miss  more  important  issues.  For  example,  a 
given  system  option  may  appear  to  be  a  bargain  in  terms  of  dollars,  but  ensuing  logistics  or 
operating  costs  may  far  exceed  other,  seemingly  more  expensive  options.  Therefore,  as  part  of  the 
research,  we  set  out  to  define  all  the  dimensions  that  encompass  total  propulsion  system  cost.  In 
addition  to  mass  and  price,  there  are  three  other  aspects  of  performance  to  consider:  volume.  Total 
elapse  thrust  time  (to  complete  all  AV),  and  power  consumed.  Finally,  there  are  other  less  obvious 
opportunity  costs  to  consider  as  well.  Collectively,  these  as  referred  to  as  mission  costs  as  they 
depend  on  the  technology  used  and  the  mission  environment.  These  are:  technical  risk,  safety, 
logistics  and  integration.  Thus,  the  nine  dimensional  cost  paradigm  includes: 

1.  Propellant  mass 

2.  Propellant  volume 

3.  Total  elapsed  thrust  time  (to  complete  desired  AV) 

4.  Power  required 

5.  System  price 

6.  Technical  risk  (to  the  program) 

7.  Safety  (to  deal  with  inherent  personal  risk) 

8.  Integration 

9.  Logistics 

Figure  I  illustrates  how  each  phase  of  a  mission  drives  the  specific  cost  dimensions.  Using  this  new 
paradigm,  the  real  cost  of  system  options  could  then  be  assessed.  This  will  be  addressed  in  the  next 
section. 

2.2  Assessing  System  Options 

Armed  with  a  new  paradigm  for  understanding  propulsion  system  costs,  all  realistic  near-term 
options  for  small  satellite  applications  were  considered.  These  options  are  listed  in  Table  1  along 
with  important  performance  parameters. 

The  chemical  systems  identified  included  traditional  solid  and  liquid  systems  as  well  as  hybrid.  For 
electric  systems,  the  study  showed  that  resistojets  and  pulsed  plasma  thrusters  (PPT)  look  the  most 
promising  for  small  satellites  due  to  their  low  power  requirement  (50  -  500  W  continuous  power). 
Ion  systems  have  been  designed  for  low  power  (-440  W),  but  are  very  expensive  (-1.5  million  for 
each  thruster).  Microwave  thrusters  can  also  function  at  low  power,  but  still  are  in  the  theoretical 
stage.  The  other  systems,  have  too  high  of  a  power  requirement  for  the  UoSAT  platform.  It  was 
decided  due  to  the  anticipated  simple  integration  requirement  for  a  water  resistojet,  that  it  would  be 
worth  pursuing  (water  can  go  anywhere  in  the  world  !).  PPT’s  are  being  studied  at  NASA  Lewis 
and  the  USAF  Phillips  Laboratory  (with  Olin  as  the  contractor)  and  will  be  attractive  as  soon  as  a 
more  advanced  systems  are  flown  [Myers  94]. 


4 


Figure  1:  Relationship  between  mission  phase  and  cost  drivers  for  propulsion  systems. 

In  addition  to  understanding  performance  costs,  the  price  and  mission  costs  for  each  option  were 
also  characterised.  System  prices  were  determined  by  designing  representative  system  architectures 
for  each  option  and  then  pricing  individual  components  based  on  information  gained  from  the 
UoSAT-12  system  design  project  (described  later  in  the  this  paper).  Mission  costs  for  each  option 
were  evaluated  based  on  a  thorough  understanding  of  each  technology  applying  engineering 
judgement.  Table  2  lists  the  relative  mission  costs  for  each  option.  These  and  all  dimensions  were 
scaled  0-100  (with  0  being  lowest  cost  and  100  highest)  to  allow  for  parametric  combination. 


System 

Isp  (sec) 

Oxidiser/ 

Propellant 

specific 

gravity 

Fuel 

specific 

gravity 

O/F 

Density 

Isp 

Thrust 

(N) 

Power 

(W) 

Bi-Propellant 

290 

1.447 

0.8788 

1.65 

337.33 

20 

2 

Hydrazine  mono-propellant 

225 

1.008 

226.80 

20 

1 

Hybrid 

295 

1.36 

0.93 

8 

381.60 

500 

1 

Cold-gas 

65 

0.23 

14.95 

0.1 

.5 

H20  Resistojet 

185 

1.0 

185.00 

0.3 

500 

Solid  (STAR  17-A) 

286.7 

1.661 

476.21 

16000 

0 

Hydrazine  Resistojet 

304 

1.008 

306.43 

0.33 

500 

PPT 

1500 

2.16 

3240.00 

WtlCTHHJ 

20 

HTP  mono-propellant 

150 

1.36 

204.00 

1 

1 

Table  1:  Performance  comparisons  between  various  propulsion  technologies  analysed. 
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Option 

Safety  Cost 
Factor 

Technical 

Risk  Factor 

Integration 

Factor 

Logistics 

Factor 

Bi-Propellant 

100 

50 

80 

100 

Hydrazine  mono-propellant 

90 

40 

70 

90 

Hybrid 

50 

100 

100 

60 

Cold-gas 

10 

10 

10 

20 

H20  Resistojet 

10 

80 

20 

20 

Solid 

20 

30 

100 

80 

Hydrazine  Resistojet 

90 

40 

40 

90 

PPT 

10 

80 

80 

10 

HTP  mono-propellant 

50 

80 

70 

60 

Table  2;  Relative  mission  costs  for  propuision  system  options. 

The  approach  taken  to  parametrically  combine  all  cost  dimensions  into  a  single  figure  of  merit  is 
illustrated  in  Figure  2.  A  mission  scenario  was  first  defined  which  determined  the  mission 
environment  and  the  total  AV  required.  The  mission  environment  determines  the  weighting  applied 
to  each  dimension.  For  example,  an  experimental  mission  sponsored  by  a  University  will  place  a 
higher  premium  on  price  than  mass  while  a  commercial  organisation  may  take  the  opposite 
approach.  Each  dimension  was  weighted  from  8-0  with  8  being  the  most  important  and  0  meaning 
no  importance  (e.g.  a  given  mission  may  place  no  weight  to  the  total  time  needed  to  complete  a 
manoeuvre).  The  mission  AV  was  used  to  determine  the  performance,  price  and  mission  costs  for 
each  option.  All  parameters  were  then  combined  using  the  following  relationship: 

Total _  Cost  =  ^  •  Pr  op_  Mass  +  5  •  Pr  op_  Vol  +  C  ■  Time  +  D  ■  Power  +  (2  1) 

E  •  Logistics  +  F  ■  Integrat  +  G  ■  Safety _  Cost  +  H  ■  Tech_  Risk  +  /  •  Pr  ice 

where 


A-I-  Weightings  on  each  dimension 

To  illustrate  the  utility  of  this  method,  it  was  applied  to  four  different  mission  scenarios. 

•  Traditional  commercial  mission — 200  m/s  AV  station  keeping.  Performance  costs 
dominate.  (Solid  option  not  considered) 

•  N on-traditional,  SSTL-type  commercial  mission — 200  m/s  AV  station  keeping.  System 
price  dominates.  (Solid  option  not  considered) 

•  Experimental  mission — Low  AV  (20  m/s).  System  price  dominates. 

•  High  risk  Lunar  orbit  mission — High  AV  (1600  m/s).  Initial  geosynchronous  transfer  orbit 
puts  a  premium  on  time  due  to  total  radiation  dose  effects.  (Cold-gas  and  PPT  options  not 
considered) 

The  weightings  applied  to  each  dimension  for  each  scenario  is  shown  in  Table  3.  Results  are  shown 
in  Table  4  and  Table  5.  Total  propellant  mass  for  each  option  and  mission  is  shown  along  with  the 
total  estimated  system  price  and  the  normalised  total  cost  computed  from  the  cost  figure  of  merit. 

It  is  important  to  emphasise  that  the  results  presented  above  are  not  intended  to  be  the  final  word. 
The  purpose  in  developing  this  process  was  to  produce  results  from  which  to  start  discussion,  not 
iron-clad  answers  intended  to  end  all  debate.  For  example,  different  schools  of  thought  may  take 
exception  with  the  exact  qualitative  values  assigned  to  certain  technology  options  or  the  weightings 
applied  to  various  dimensions  for  a  given  mission  scenario.  The  results  may  differ  depending  on  the 
actual  assumptions  made,  although,  the  process  used  remains  the  same.  Therefore,  the  more  general 
conclusions  about  the  utility  of  the  process  itself  are  the  most  important  to  consider. 
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Figure  2:  Basic  approach  for  applying  the  total  cost  figure  of  merit. 


Rank 

(weighting 
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Traditional 

Commercial 

Mission 
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Commercial 

Mission 

Experimental 

Mission 

Lunar  Orbit 
Mission 

8 

Mass 

Price 

Price 

Time 

7 

Volume 

Integration 

Integration 

Price 

6 

Technical  Risk 

Safety 

Logistics 

Safety 

5 

Integration 

Logistics 

Safety 

Logistics 

4 

Logistics 

Technical  Risk 

Power 

Integration 

3 

Safety 

Mass 

Volume 

Technical  Risk 

2 

Price 

Volume 

Technical  Risk 

Volume 

1 

Power 

Power 

Mass 

Mass 

0 

Time 

Time 

Time 

Power 

Table  3:  Weightings  applied  to  cost  dimensions  for  various  mission  scenarios. 


To  begin  with,  this  unique  method  for  comparing  system  options  provides  a  versatile  tool  for 
mission  planners  that  allows  them  to  quickly  quantify  and  compare  all  available  technologies  and 
assess  their  relative  total  mission  costs.  Thus,  for  the  first  time,  complex  system  information  can  be 
easily  quantified.  Low-cost  satellite  engineering  at  the  University  of  Surrey  and  elsewhere  has 
epitomised  the  virtue  of  applying  appropriate  technology  to  a  given  problem.  The  appropriateness  of 
a  technology  is  judged  by  taking  a  wider  view  that  encompasses  more  than  simply  price  or 
performance.  Until  now,  engineers  typically  relied  on  completely  subjective  engineering  judgement 
or  “gut  feeling”  in  order  take  into  account  such  indirect  cost  factors  as  integration  and  safety.  The 
total  cost  figure  of  merit  process  now  provides  a  quantifiable  means  of  making  those  important 
engineering  decisions. 
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Mission 

System 

Propellant 
Mass  (kg) 

Cost  Figure 
of  Merit 

Traditional 

Commercial 

PPT 

3.37 

$500,000 

47.4 

Hydrazine  Resistojet 

16.22 

$229,942 

74.3 

H2O  Resistojet 

26.09 

$119,604 

77.7 

Hybrid 

16.69 

$171,701 

84.3 

Bi-Propellant 

16.97 

$176,987 

84.9 

Hydrazine  mono¬ 
propellant 

21.66 

$132,724 

88.8 

HTP  mono-propellant 

31.77 

$122,724 

100.0 

Hydrazine  Resistojet 

1.67 

$217,160 

3.2 

Non-Traditional 

Commercial 

H2O  Resistojet 

26.09 

$119,604 

56.2 

PPT 

3.37 

$500,000 

76.1 

HTP  mono-propellant 

31.77 

$122,724 

86.3 

Hydrazine  Resistojet 

16.22 

$229,942 

90.0 

Hybrid 

16.69 

$171,701 

91.7 

Hydrazine  mono¬ 
propellant 

21.66 

$132,724 

92.0 

Bi-Propellant 

16.97 

$176,987 

100.0 

Table  4:  Summary  of  cost  analysis  results  for  traditional  vs.  non-traditional  commercial  mission 

scenarios. 


Mission 

System 

Propellant 
Mass  (1^) 

System 
Price  ($) 

Cost  Figure 
of  Merit 

Experimental 

Cold-gas 

7.72 

$77,594 

30.9 

H2O  Resistojet 

2.82 

$94,040 

46.7 

HTP  mono-propellant 

3.37 

$97,160 

65.4 

PPT 

0.34 

$200,000 

67.4 

Hydrazine  mono¬ 
propellant 

2.26 

$107,160 

79.5 

Hybrid 

1.72 

$171,701 

89.2 

Hydrazine  Resistojet 

1.67 

$217,160 

97.9 

Bi-Propellant 

1.75 

$176,987 

100.0 

Lunar  orbit 

Hybrid 

106.18 

$248,393 

49.0 

HTP  mono-propellant 

165.72 

$237,762 

59.1 

Hydrazine  mono¬ 
propellant 

128.90 

$260,544 

59.8 

Bi-Propellant 

107.54 

$279,243 

64.0 

Solid  (2  X  STAR  17-A) 

108.46 

$1,420,000 

68.5 

H2O  Resistojet 

148.98 

$272,988 

69.6 

Hydrazine  Resistojet 

103.80 

$332,198 

100.0 

Table  5:  Summary  of  Total  System  Cost  analysis  results  for  an  experimental  mission  and  a  Lunar 

orbit  mission. 

Furthermore,  because  the  process  results  in  a  quantifiable  parameter,  it  can  serve  as  a  useful  total 
quality  planning  tool.  By  quantifying  the  starting  point  for  various  options,  this  technique  can 
provide  important  indications  of  where  best  to  invest  in  improvement  and  enables  any  incremental 
improvements  to  be  measured.  In  this  way,  the  controversial  results  reported  above  may  help  to 
spark  debate  and  force  a  re-examination  of  research  priorities  for  small  satellite  propulsion.  For 
example,  in  deciding  where  best  to  invest  money  in  a  PPT  development  program,  this  process  (as 
evidenced  by  the  results  above)  would  indicate  that  more  effort  should  be  aimed  at  lowering  the 
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price  and  integration  complexity  of  the  thruster  rather  than  on  increasing  its  delivered  Isp.  In  doing 
this,  it  would  clearly  offer  a  better  overall  cost-effective  solutions  to  competing  options. 

The  most  immediate  application  for  this  method  as  a  research  planning  tool  is  at  the  University  of 
Surrey.  These  results  indicate  that  three  propulsion  technologies  offer  real  benefit  for  future 
mission  scenarios: 

•  Hybrid  rockets — for  future  high  AV  options  such  as  the  Lunar  mission  (with  the  HTP 
mono-propellant  system  as  a  necessary  bi-product  of  such  research). 

•  H2O  resistojet — for  commercial  applications  for  the  minisatellite  bus  for  station  keeping 
requirements  in  LEO  or  GEO. 

•  Cold-gas — for  near-term  experimental  missions  to  develop  basic  orbit  control  techniques. 
These  research  areas  will  be  addressed  in  the  following  sections. 

2.3  Hybrid  Rocket  Research 

Based  on  the  analysis  presented  in  the  last  section,  hybrid  rockets  emerged  as  a  promising 
technology  in  need  of  further  research.  Hybrid  rockets  offer  an  inherently  safe  option  that  use  a 
liquid  oxidiser  and  a  solid  fuel.  In  operation,  they  cannot  explode.  The  following  subsections 
describes  the  research.  Additional  background  on  the  program  can  be  found  in  [Sellers  94b] 
[Sellers  95a]. 

2.3.1  Research  Objectives 

Beginning  in  April  1994,  supported  by  UoSAT/SSTL,  we  undertook  this  ambitious  hybrid  rocket 
research  programme.  The  goals  of  the  program  were  established  as  follows: 

1 .  Proof-of-concept — demonstrate  the  accessibility  of  hybrid  rocket  technology  for  continued 
research,  development  and  exploitation  for  low-cost  satellite  upper  stages.  In  the  process, 
identify  and  solve  the  critical  engineering  problems  of  the  technology. 

2.  Performance  characterisation — recognising  that  the  actual  performance  of  a  given  hybrid 
propellant  combination  depends  on  empirical  data,  establish  through  experimental 
investigation,  the  regression  rate  characteristics  for  a  proto-type  motor  and  use  this  data  as 
a  basis  for  preliminary  upper  stage  design  calculations. 

3.  Total  cost  assessment — based  on  the  experience  gained  through  hands-on  hybrid  rocket 
work,  fully  assess  the  system  price  and  mission  costs  for  future  hybrid  upper  stage 
applications. 

With  these  objectives  in  mind,  a  proto-type  hybrid  motor  was  designed,  built  and  tested  using  85% 
high  test  hydrogen  peroxide  oxidiser  (HTP)  and  polythene  fuel. 

2.3.2  Results  &  Conclusions 

The  primary  objectives  of  the  hybrid  research  program  have  already  been  met.  To  begin  with,  the 
concept  has  been  proven.  Hybrids  represent  a  readily  assessable  technology  allowing  full-scale 
research  and  development  in  a  budget-constrained.  University  environment.  The  program 
demonstrated  rapid  results  (first  successful  test  less  than  7  months  from  project  go-ahead)  with 
minimum  cost  (<  $20,000)  and  addressed  and  solved  a  number  of  fundamental  engineering 
problems,  most  notably  catalyst  pack  technology.  55  catalyst  pack  tests  were  completed  using  8 
different  catalyst  types.  9  successful  hybrid  tests  were  completed. 

Experimental  results  allowed  the  complete  characterisation  of  hybrid  performance.  The  proto-type 
hybrid  motor  was  used  to  fully  assess  the  PE/HTP  combination  and  publish  the  first-ever  regression 
rate  relationship  applied  specifically  to  small  satellite  upper  stages.  This  data  is  shown  in  Figure  3. 
Using  this  data,  a  hybrid  upper  stage  design  process  was  developed  and  a  preliminary  design  for 
minisatellite  motor  was  completed.  Performance  parameters  for  this  motor  are  shown  in  Table  6. 
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Experimental  Regression  Rate  Data  with  Derived  Regression 
Rate  Equation 


»  Expimental  Data 
Derived  B:|uation 
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Figure  3:  Regression  rate  data  for  85%  HTP/PE  hybrid  combination. 


Parameter 

Value 

Initial  port  radius  (m) 

0.008 

Initial  L/D 

25 

Ave.  Isp  (sec)* 

299.6 

Ave.  0/F 

8.4 

Total  propellant  mass  (kg) 

16.5 

Fuel  mass  (kg) 

1.8 

Oxidiser  flow  rate  (kg/s) 

0.123 

HTP  volume  (litre) 

10.8 

Ave.  Thrust  (N) 

404 

Thrust  time  (sec) 

120 

Total  impulse  (Ns) 

48,480 

Throat  diameter  (m) 

0.0062 

Expansion  Ratio 

150:1 

Nozzle  length  (m) 

0.268 

Motor  length  (m)** 

0.25 

Table  6:  Results  of  spacecraft  hybrid  motor  design  exercise.  Performance  is  assumed  to  be  95%. 

Port  geometry  is  assumed  to  be  “double-D.” 

Finally,  the  total  cost  of  hybrids  with  respect  to  the  cost  paradigm  were  assessed.  The  performance 
costs  for  200  m/s  AV  motor  were  defined  above.  Development  price  for  the  motor  described  earlier 
were  estimated  to  be  100,000  with  total  system  cost  $170,000. 

Obviously,  the  first  flight  of  any  new  propulsion  technology  caries  technical  risk  to  the  mission. 
Fortunately,  the  inherent  nature  of  hybrids  makes  the  chance  of  a  catastrophic  failure  extremely  low. 
Once  hybrid  technology  has  overcome  the  stigma  of  being  untried  in  space,  these  inherent  features 
would  make  its  overall  technical  risk  roughly  equivalent  to  mono-propellant  technology. 

The  combined  thermal  control  and  ADCS  aspects  of  hybrid  motor  integration  costs  would  be 
roughly  the  same  as  those  discussed  for  solid  motors.  In  addition,  hybrids  have  a  significant  overall 
integration  advantage  over  solids  in  that  the  motor  can  be  fully  integrated  within  the  spacecraft  prior 
to  shipment.  Launch  site  preparation  would  require  only  the  loading  of  oxidiser.  Figure  4  gives  a 
cut-away  view  of  the  hybrid  motor  described  earlier  installed  in  the  minisatellite  structure.  The 
mechanical  integration  complexity  for  a  hybrid  would  be  similar  to  a  mono-propellant  system  in 
terms  of  overall  requirements  for  support  systems  (tanks,  valves,  etc.). 
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Figure  4:  Cut-away  diagram  showing  possible  configuration  of  a  hybrid  motor  and  support  tanks 

within  the  minisatellite  structure. 

Safety  issues  associated  with  small  satellite  applications  for  hybrids  arise  from  two  sources: 

•  Storage  and  handling  of  high  pressure  gas 

•  Storage  and  handling  of  HTP 

The  first  safety  issue  is  not  unique  to  hybrids  and  must  be  addressed  as  part  of  cold-gas  or  other 
liquid  propellant  options  (bi-propellant,  mono-propellant  or  resistojet).  As  discussed  in  Chapter  4, 
procedures  and  regulations  governing  high  pressure  gasses  are  well  established.  References  such  as 
[MS  1522 A]  specify  design  criteria  for  tanks  and  lines  to  ensure  safe  operation. 

The  second  issue  is  the  most  important  to  address.  A  fair  assessment  of  the  safety  aspects  of  HTP 
must  be  done  in  context  with  other  propellant  options  such  as  hydrazine,  MMH  or  MON.  Both 
[CPI A  84]  and  [HPHB  67]  provide  extensive  background  on  HTP  safety  requirements. 

While  HTP  can  cause  skin  irritation,  [HPHB  67]  classifies  it  as  non-toxic  in  sharp  contrast  to  other 
liquid  propellants.  This  greatly  alleviates  demands  on  the  necessary  safety  infrastructure  as 
“respiratory  protection  is  ordinarily  not  required”  [CPIA  84]  in  sharp  contrast  to  hypergolics  which, 
as  Chapter  4  describes,  require  the  use  of  full  SCAPE  suits.  For  HTP  handling,  much  less 
expensive  and  complex  vinyl-coated  trousers,  coats  and  hoods  with  Plexiglas  face  protection  are 
sufficient.  Ordinary  rubber  gloves  (purchased  from  TESCO)  offer  adequate  protection  for 
equipment  handling. 

The  biggest  potential  impact  of  safety  considerations  on  mission  costs  relates  to  logistics.  HTP 
must  either  be  delivered  to  the  launch  site  by  the  supplier  (e.g.  Air  Liquide)  or  directly  to  the 
satellite  manufacturer  for  shipment  as  part  of  the  overall  launch  campaign.  According  to  [CPIA 
84],  HTP  is  authorised  for  transport  aboard  military  aircraft  when  packaged  in  accordance  with 
DOT  regulations  which  defines  it  as  an  oxidiser  under  IJN2015.  Unfortunately,  it  cannot  be  carried 
on  commercial  aircraft  in  any  quantity.  However,  discussions  with  supplier  Air  Liquide  [Tremblot 
96]  indicates  that  the  rules  governing  HTP  ground  transport  are  the  same  that  apply  to  70% 
hydrogen  peroxide  which  is  used  world-wide  in  the  pulp  and  paper  industry.  Therefore,  ground 
transportation  of  even  very  large  quantities  virtually  any  where  in  the  world  would  be  relatively 
easy  to  arrange  given  sufficient  delivery  notice. 

2.4  Water  Resistojet  Research 

This  section  will  describe  the  water  resistojet  research  at  the  University  of  Surrey.  Background  on 
the  technology  will  first  be  discussed.  Research  objectives  will  then  be  reviewed  followed  by  a 
discussion  of  preliminary  results. 


2.4.1  Background 

A  resistojet  can  be  classified  as  an  electrothermal  thruster  in  that  electrical  energy  is  used  to  directly 
heat  a  working  fluid.  The  resulting  hot  gas  is  then  expanded  through  a  converging-diverging  nozzle 
to  achieve  high  exhaust  velocities.  As  with  chemical  rockets  (which  produce  heat  stored  in 
chemical  bonds),  the  same  concerns  exist  for  the  relative  energy  in  kinetic  vs  internal  energy,  as 
well  as  for  the  loss  of  energy  due  to  heat  transfer  and  radiation.  The  primary  difference  is  that  for 
resistojets,  the  electrically  heated  channel  wall  has  a  higher  temperature  than  the  flow.  Thus,  the 
performance  is  limited  by  the  channel  wall  temperature.  However,  the  advantage  of  a  resistojets  is 
that  any  working  fluid  can  be  used  as  a  propellant.  Figure  8  shows  the  specific  impulse,  Isp,  and 
density  specific  impulse  for  various  working  fluids  for  a  gas  chamber  temperature,  Tc,  of  1000  K. 

isp  and  Density  Isp  for  Various  Working  Fluids  at 
Tc  =  1000  K 
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Figure  5:  Comparisons  of  specific  impulse  (Isp)  and  density  specific  impulse  for  various  resistojet 

propellant  options. 

The  advantage  of  using  water  as  the  working  fluid  was  illustrated  in  the  analysis  presented  above. 
Not  only  does  it  offer  high  density  and  low  mass  in  terms  of  performance  costs,  but  its  inherently 
safe  nature  make  potential  technology  development  costs  low  as  well. 

2.4.2  Research  Objectives 

Beginning  in  November,  supported  by  UoSAT/SSTL,  we  started  a  development  effort  studying 
electric  propulsion  options  for  small  satellites.  Based  upon  the  results  discussed  above,  and  a 
preliminary  feasibility  study,  water  resistojets  looked  very  attractive  for  stationkeeping  missions. 
The  goals  of  the  programme  were  established  as  follows: 

1)  Proof-of-concept — Demonstrate  the  accessibility  of  water  resistojet  technology  for 
continued  research,  development  and  exploitation  for  low-cost  satellite  stationkeeping 
missions.  In  the  process,  identify  and  solve  the  critical  engineering  problems  of  the 
technology.  This  goal  was  broken  down  into  the  following  tasks: 

•  Design  a  proof-of-concept  thruster  (called  the  Mark-I) 

•  Establish  test  infrastructure. 

•  Investigate  heat  transfer  trade-offs 

2)  Performance  characterisation — Unlike  performance  for  chemical  rockets  which  can  be 
readily  predicted  from  combustion  thermochemistry,  the  theoretical  performance  of  a 
water  resistojet  must  rely  on  less  analytical  approximations  of  heat  transfer  efficiency. 
This  can  become  a  complicated  problem  as  the  heat-transfer  correlations  for  the  various 
transitions  of  water-steam  boiling  and  two-phase  flow  are  difficult  to  model- 
thermodynamic  properties  are  very  dependent  on  the  steam/liquid  mixture.  The  high 
temperatures  and  low  thrust  for  electrothermal  thrusters  has  traditionally  led  to  a 
requirement  for  highly  sophisticated  (and  very  expensive)  thrust  stands  to  get  accurate 
performance  characterisation.  One  of  the  primary  reseasrch  goals  during  this  phase  will 
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be  to  develop  an  analytic  technique  to  acuately  model  resistojet  performance  based  upon 
thermodynamic  heat  transfer  efficiencies.  These  predictions  will  be  compared  to 
experimental  results.  Once  a  credible  analytic  approach  is  established,  the  thruster  will 
then  be  tested  on  a  state-of-the-  art  thrust  stand  to  further  validate  the  technique.  It  is 
envisioned  that  such  an  analytic  performance  prediction  technique  will  enhance  the  state 
of  the  art  for  these  types  of  thrusters  by  eventually  reducing  or  eliminating  the  need  for 
complex  and  expensive  thrust  measurement  equipment.  The  end  result  will  be  a  low-cost 
approach  to  electrothermal  rocket  testing.  This  objective  will  also  consist  of  three  tasks: 

•  Based  on  experience  gained  during  Phase- 1,  design  a  more  efficient 
experimental  thruster  (called  the  Mark-II) 

•  Define  performance  prediction  trade-offs  and  heat  transfer  correlations 

•  Collect  experimental  data  over  a  wide  range  of  operating  regimes 

•  Address  satellite  integration  and  operations  issues 

3)  On-Orbit  Demonstration — The  final  goal  of  this  research  will  be  an  on-orbit 
demonstration  of  the  technology.  This  will  represent  a  true  “first”  as  no  water  resistojet 
has  ever  been  tested  in  space.  This  experiment  will  be  conducted  on  the  UoSAT-12 
mission  (described  below).  Care  must  be  taken  to  ensure  the  experimental  thruster  firings 
are  compatible  with  the  spacecraft’s  duty  cycle.  Simulation  of  the  operations  concept 
will  be  incorporated  early  on  in  the  research  programme  to  insure  the  optimum  solution  is 
obtained.  The  duty  cycle  will  be  optimised  for  the  UoSAT-12  mission  but  will  be 
designed  to  demonstrate  the  operational  flexibility  of  the  technology  to  meet  the 
requirements  for  future  station  keeping  missions.  A  proto-flight  thruster  (called  the 
Mark-IIT)  based  on  the  following  performance  parameters  is  envisioned  for  UoSAT-12: 

•  Thrust  =  0.05  -  0.5  N 

•  Specific  impulse  =  180  -  220  sec 

•  Power  =  100-  560  W 

•  Duration  =  >  250  minutes  total  operation. 

2.4.3  Program  Status 

The  program  is  currently  in  the  Proof-of-Concept  Phase.  The  Mark-I  thruster  has  been  designed 
and  fabricated.  For  the  Mark-1  design,  it  was  understood  that  there  were  many  ways  the  thrust 
chamber  could  be  configured  to  give  efficient  heat  transfer  to  the  propellant  (a  tube  wrapped  in  a 
electric  coil,  directly  exposing  the  propellant  to  an  electric  coil,  a  heater  surrounded  by  sintered 
material  or  a  heater  surrounded  by  a  packed  bed  of  heat  transfer  material).  Such  designs  are 
discussed  in  [Morren  88]  and  [Morren  93a].  We  decided  to  pursue  the  packed  bed  approach  as  it 
provides  high  surface  area  and  therefore  the  potential  for  high  heat  transfer.  An  additional 
advantage  of  a  packed  bed  is  the  relatively  high  pressure  drop  created  which  allows  for  very  long 
propellant  stay  time,  further  increasing  heat  transfer  efficiency.  Predicted  results  for  various  heat 
transfer  material  is  shown  in  Figure  6. 

The  Mark-I  thrust  chamber  is  30  cm  by  120  cm  with  a  10  by  110  cm  commercial  cartridge  heater 
installed  in  the  centre.  Around  the  heater,  the  chamber  is  packed  with  a  heat  transfer  material 
(leading  candidates  are  stainless  steel,  boron  carbide,  and  silicon  carbide)  in  the  form  of  pellets 
varying  from  300  -  700  pm  in  diameter.  Water  flow  rate  varies  from  0.05  to  .1  g/sec  at  an  inlet 
pressure  of  10  bar.  As  it  enters  the  chamber,  the  water  passes  through  a  2  mm  sintered  disk  which 
keeps  the  heat  transfer  material  from  interacting  with  the  injector  and  also  provides  a  pressure  drop 
to  decouple  the  inlet  pressure  from  the  chamber  pressure  (otherwise  flow  oscillations  can  regulate 
the  inlet  flow).  The  water  then  flows  across  the  bed,  is  heated,  and  passed  out  through  the  .5  mm 
throat  diameter  nozzle  as  super-heated  steam.  The  instrumentation  in  the  thrust  chamber  consists  of 
two  pressure  gauges  and  12  thermocouples.  A  cut-away  drawing  of  the  thrust  chamber  is  shown  in 
Figure  7. 
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Predicted  Performance  for  10  Minute  start-up 
for  Water  using  Various  Heat  Transfer  Material 
(Power  =  500W) 


Time  (sec) 


Figure  6:  Predicted  performance  for  water  resistojet  with  various  be  materials  (SS  =  stainless  steel, 

B4C  =  boron  carbide) 


Figure  7:  Cut-away  diagram  of  experimental  water  resistojet. 

Preliminary  tests  using  stainless  steel  as  the  heat  transfer  material  have  been  conducted  for  up  to  6 
hours  of  thruster  operation  expanding  to  atmosphere.  As  the  program  is  still  in  the  proof-of-concept 
phase,  actual  thruster  performance  data  has  not  yet  been  produced.  However,  the  test  infrastructure 
has  been  validated  and  the  Mark-I  design  has  proved  useful  for  understanding  heat  transfer  trade¬ 
offs.  Initial  results  indicate  reliable  heat  transfer  within  the  bed  with  temperatures  >600  K 
achievable,  which  is  consistent  with  earlier  results  [Morren  88].  The  Mark-II  thruster  is  currently 
being  designed  for  full-scale  performance  characterisation  beginning  in  July  1996.  We  are  looking 
at  techniques  for  improving  heat  transfer  efficiency  (e.g.  insulation,  pre-heaters,  greater  stay  time, 
etc.).  This  program  is  on  a  fast-track  to  produce  a  proto-flight  thruster  for  UoSAT-12  by  December 
1996. 

2.5  Uosat-1 2  System 

Concurrent  with  this  research,  engineers  at  SSTL/UoSAT  were  designing  a  flexible,  multi-mission 
minisatellite  to  position  themselves  to  exploit  the  emerging  opportunities  discussed  above.  With  an 
approximate  mass  of  250  kg,  the  minisatellite  structural  design  builds  on  the  modular  approach  used 
in  the  UoSAT  microsatellites  in  a  way  that  allows  maximum  re-use  of  subsystems  between  the  two 
platforms.  The  minisatellite  structure  starts  with  a  honeycomb  attach  frame  on  which  three  stacks 
of  module  boxes  are  arranged  in  a  triangle.  Solar  panels  of  the  same  width  as  those  used  on  the 
microsatellites  are  arranged  around  the  sides  to  get  a  total  of  nine  sides.  By  extending  the  height  of 
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the  panels,  an  equipment  or  payload  bay  is  formed  at  the  top  of  the  module  box  stack.  A  diagram  of 
the  minisatellite  is  shown  in  Figure  8.  As  this  is  written,  the  first  flight  of  this  new  satellite  bus, 
dubbed  UoSAT-12,  is  in  critical  design  for  a  launch  in  Mid- 1997. 

The  technical  objectives  for  the  minisatellite  mission  strike  a  compromise  between  all  the  features  a 
flexible  minisatellite  bus  would  have  and  what  can  be  achieved  within  the  available  budget  and  time 
scale.  The  following  technical  objectives  have  been  defined  for  the  UoSAT-12  mission: 

•  Demonstrate  a  commercially  viable  minisatellite  bus  with  industry-standard  support 
systems 

•  28  VDC  power  bus 

•  1  MBPS  S-band  down-link 

•  Demonstrate  that  enhanced  core  microsatellite  technologies  can  be  used  in  a  minisatellite: 

•  Intel  386-based  on  board  computers  (OBC) 

•  Low-rate  VHF/UHF  data  links 

•  Distributed  TT&C  via  control  area  network  (CAN) 

•  Demonstrate  major  new  subsystems: 

•  Enhanced  attitude  determination  and  control  capability 

•  Propulsion  system  capability  with  orbit  maintenance  and  attitude  control 

•  Enhance  existing  UoSAT  payloads  using  resources  of  the  minisatellite  to  provide 
operational  demonstration  of: 

•  High-resolution  (<30  m)  multi-spectral  visible  imaging 

•  Store-and-forward  communications  to  small  terminals 


Figure  8:  Diagram  of  University  of  Surrey  Minisatellite  (dimensions  in  mm). 

Figure  9  shows  the  schematic  of  the  propulsion  system  layout  for  UoSAT-12.  Note  as  this  is  an 
experimental  mission  designed  to  gain  experience  in  propulsion  system  integration  and  operations, 
the  most  cost-effective  option  (as  indicated  earlier)  was  a  cold-gas  system.  A  separate  water 
resistojet  experiment  is  also  planned.  Table  7  summarises  the  total  performance  available. 
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Cold-Gas  Thrusters 
(8  X  attitude  control,  2 
X  orbit  control) 


Figure  9:  Schematic  of  UoSAT-12  propulsion  system. 


Performance 

Parameter 

Value 

Mass  N2 

7.1  kg 

Total  Pulses 

4.384  X  10^  (0.1  sec 
each) 

Total  Impulse  (cold 
gas) 

4.389  X  10^  Nsec 

Total  Angular  Impulse 
(cold  gas) 

2.085  X  10^  Nmsec 

AV  available  (cold 
gas) 

17.8  m/s 

Mass  H2O 

1.5  kg 

Total  Impulse 
(resistojet) 

1.5  X  105  Nsec 

Table  7:  Summary  of  performance  parameters  for  UoSAT-12  propulsion  system. 
3.  CONCLUSIONS 


The  most  cost-effective  propulsions  system  can  only  be  found  by  weighing  all  options  along  the 
nine  dimensions  of  the  total  cost  paradigm  within  the  context  of  a  given  mission.  For  very  low- 
cost,  logistically  constrained  missions,  unconventional  options  such  as  hybrids  and  water  resistojets 
offer  many  unique  advantages  over  current  off-the  shelf  options.  Future  research  will  focus  on 
demonstrating  these  technologies  in  orbit. 
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Abstract 

For  analysing  the  sub-millimeter  radiation  received  by  a  astronomy  satellite,  a  hybrid 
analog-digital  spectrometer  is  planned.  As  a  critical  part  of  this  instrument,  a  specific 
digital  signal  processing  chip  set  is  proposed.  A  first  strategy  is  based  on  a  GaAs 
MESFET  chip  expected  to  perform  52  giga-operations  per  second  with  a  400  MHz 
clock  frequency.  While  this  strategy  gave  encouraging  results  and  remains  the  main  line 
of  the  project,  a  second  strategy  based  on  parallelism  on  silicon  only  is  under  study, 
and  the  opportunity  of  working  simultaneously  on  two  opposite  approaches  is  discussed. 

Keywords  :  mixed  analog-digital,  MESFET,  digital  signal  processing,  parallelism, 
auto-comelator,  space  telescope,  digital  spectrometer. 
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fig.  1  :  Satellite  bearing  the  spectrometer 
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1.  The  Instrument 


The  analysis  of  sub-millimeter  radiation  (0.1mm  <  X  <  1mm)  coming  from  "cold 
media"  can  help  understanding  the  composition  of  interstellar  clouds,  observing 
the  generation  of  stars  and  planets  and  even  detecting  planets  and  their  natural 
satellites. 

The  frequency  spectrum  of  this  radiation  carries  information  not  only  on  the 
physical  and  chemical  composition  of  the  objects,  but  also  on  the  relative  speed 
of  these  objects  (Doppler  effect). 

An  example  of  project  aimed  at  exploring  this  new  domain  is  the  FIRST  satellite 
(Far  InfraRed  and  Sub-millimeter  Space  Telescope)  that  is  to  be  launched  by  the 
European  Space  Agency  around  year  2006.  (figure  1) 

In  such  a  satellite,  the  raw  data  provided  by  the  sub-millimeter  receiver  occupies 
a  wide  bandwidth  (for  example  2  GHz)  even  when  the  meaningfull  spectrum 
information  represents  a  only  few  kHz. 

The  reason  of  this  bandwidth  reduction  is  that  the  spectral  values  must  be 
integrated  during  at  least  some  seconds  to  obtain  something  else  than  pure 
random  noise. 

(Notice  that  the  initial  signal/noise  ratio  is  one  order  of  magnitude  below  unity) 

It  is  absolutely  necessary  to  perform  this  processing  (analysis  and  integration)  on 
board  of  the  satellite,  in  order  to  keep  at  a  reasonable  level  the  cost  of 
transmitting  the  data  down  to  the  Earth. 

This  implies  that  the  instrument  will  have  to  comply  with  very  severe  constraints 
of  weight,  power  consumption  and  reliability. 

2.  The  mixture  of  Analog  and  Digital 

Pure  analog  solutions  exist  :  for  example  the  acousto-optical  spectrometer  [1]. 

It  gives  fine  results,  but  has  the  following  drawbacks  : 

-  high  sensitivity  to  environment  (temperature,  vibrations) 

-  lack  of  flexibility,  specially  in  terms  of  spectral  resolution, 

-  accuracy  drift  problems,  like  any  analog  processor. 

A  pure  digital  solution  with  the  required  bandwidth  is  not  permitted  by  the 
present  state  of  the  art. 

The  authors  chose  to  develop  an  advanced  hybrid  analog-digital  instrument,  with 
the  following  expected  benefits  [2]  : 

-  some  kind  of  robustness,  easy  "space  qualification" 

-  possibility  of  improving  the  spectral  resolution  as  it  is  needed 

-  stable  accuracy 
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fig.  2  :  The  signal  flow  in  the  two  strategies 


In  the  proposed  approach,  the  initial  bandwidth  of  some  2  GHz  will  be  first  cut 
into  slices  by  means  of  analog  circuitry,  each  slice  some  180  MHz  being  down- 
converted  and  then  sampled  at  400MHz  and  digitized  (this  is  the  minimal 
possible  amount  of  analog  processing)  (figure  2). 

Then  the  digital  part  of  the  instrument  will  compute  the  integrated  autocorrelation 
function  of  the  signal,  easier  to  compute  than  the  actual  spectrum  and  carrying 
the  same  information  at  the  same  cost  (the  spectrum  will  be  computed  on  Earth 
by  means  of  the  Fourier  transform). 

One  question  is  what  resolution  is  needed  for  the  analog  to  digital  conversion. 
Theoretical  computation  [3]  showed  that  the  value  of  two  bits  is  suitable  for  the 
project. 

At  first  glance,  one  may  be  surprised  reading  that  two  bits  only  are  used  to 
digitize  a  signal  containing  much  more  noise  than  information.  To  give  a 
simplified  explanation,  let  us  state  that  the  statistical  properties  of  the  thermal 
noise  and  of  the  quantification  noise  allow  to  reject  them  after  processing 
thousands  of  millions  of  samples,  even  if  both  noises  are  much  greater  than  the 
signal  coming  from  the  interstellar  cold  media. 

In  the  other  hand,  only  a  few  microvolts  of  deterministic  noise  injected  in  the 
analog  part  may  corrupt  the  measurements,  this  is  why  the  analog  part  must  be 
well  separated  from  the  digital  one. 
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3.  The  basic  autocorrelator,  or  the  strategy  #  1 


The  discrete  autocorrelation  function  of  a  digitized  signal  can  be  computed  by 
means  of  time  delays  and  multiplications.  A  regular  structure  is  constructed  on 
the  basis  of  a  folded  delay  line  :  fig.  3. 

This  structure  can  be  described  as  a  set  of  similar  channels,  each  channel 
computing  one  sample  of  the  autocorrelation  function.  Channel  N  gives  the 
product  of  the  signal  with  its  image  delayed  by  N  times  the  sampling  period, 
while  channel  zero  gives  the  square  of  the  signal. 

These  products  are  then  integrated  by  accumulators  (one  per  channel,  not 
represented  on  fig.  3),  and  the  contents  of  the  accumulators  is  transmitted  to  the 
user  at  the  end  of  each  integration  period  (a  few  seconds). 

A  large  accumulation  capacity  is  needed  (e.g.  35  bits),  since  the  integration 
period  (e.g.  5  seconds)  is  very  long  compared  to  the  sampling  period  (2.5  ns). 

In  fact,  only  the  most  significant  bits  (e.g.  16  bits)  of  the  accumulated  value  are 
meaningful  for  the  user,  due  to  the  domination  of  thermal  noise  in  the  incoming 
signal. 


D  flip-flop 


Multiplier 


fig.  3  :  The  single  folded  delay  line  architecture 


Notice  that  in  figure  3,  the  signal  lines  carry  actually  2  bits  of  data,  and  each  of 
the  square  boxes  representing  the  delay  elements  contains  actually  2  flip-flops. 


3.1.  GaAs  against  silicon  in  strategy  #  1 

The  power  consumption  is  the  most  critical  issue  for  this  system,  like  for  any 
space  equipment. 

On  the  silicon  side,  the  bipolar  ECL  logic  could  run  at  the  desired  speed,  but 
with  a  great  power  consumption  and  a  poor  area  efficiency. 
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CMOS  is  not  as  fast,  even  if  submicron  CMOS  circuits  have  been  run  at  200 
MHz.  The  problem  with  ultra  high  speed  CMOS  is  the  power  consumption, 
partly  because  of  the  large  voltage  swing  of  the  logic  signals. 

A  good  competitor  is  the  GaAs  MESFET  technology  with  DCFL  gates  (Direct 
Coupled  FET  logic).  The  DCFL  gates  have  a  simple  architecture,  built  with 
enhancement  and  depletion  N-channel  JFETs  in  a  manner  that  recalls  the  early 
NMOS  logic,  even  if  the  electrical  behaviour  is  quite  different  due  to  the  direct 
gate-to-source  current  [4]. 

The  small  logic  voltage  swing  and  the  small  supply  voltage  are  the  keys  of  a 
good  speed/power  ratio  [5]. 

DCFL  is  the  most  compact  solution  for  digital  GaAs,  the  integration  density  is 
comparable  with  static  sub-micron  CMOS. 

A  high  integration  density  is  wanted  not  for  cost  reasons,  but  mainly  because  it 
has  an  indirect  influence  on  the  total  power  consumption  :  a  poor  density  would 
lead  to  a  greater  number  of  interconnected  chips,  dissipating  lots  of  power  in  I/O 
buffers. 

Let  us  remark  that  below  some  60  MHz,  CMOS  consumes  less  power  than 
GaAs,  and  that  the  difference  is  very  important  at  low  frequencies. 

In  the  autocorrelator,  a  significant  part  of  the  integration  task  can  be  performed 
below  60  MHz.  This  is  why  the  proposed  architecture  is  composed  of  a  GaAs 
chip  for  shifting,  multiplications  and  first  stages  of  integration,  down  to  a 
bandwidth  of  12.5  MHz,  (sampling  at  25  MHz)  and  a  CMOS  chip  for  the 
remainder  of  the  integration  (figure  2,  strategy  #  1). 

3.2  Mixing  synchronous  and  asynchronous  design 

The  desired  integration  duration  requires  an  accumulator  capacity  of  35  bits  for 
each  channel. 

Considering  that  at  the  end  of  the  integration  period  only  the  16  most  significant 
bits  will  be  transmitted  to  the  end  user,  we  note  that  the  19  less  significant  bits 
of  the  accumulated  result  do  not  need  to  be  available  in  parallel  form. 

Thus,  a  solution  using  an  asynchronous  cascade  counter  to  perform  the  integration 
would  be  minimal  in  terms  of  area  and  power,  and  would  allow  to  defer  to  a 
CMOS  chip  some  three  quarters  of  the  integration  task. 

The  complete  solution  is  complicated  by  the  fact  that  the  actual  output  of  each 
mutiplier  must  be  first  accumulated  synchronously,  and  it  is  the  overflow  of  this 
operation  that  will  be  chopped  and  directed  to  an  asynchronous  cascade  counter 
(5  stages  down  to  12.5  MHz  bandwidth). 

The  outputs  of  the  64  channels  of  the  GaAs  chip  have  to  be  multiplexed  by  4:1 
for  transmission  to  the  CMOS  chip  using  a  reasonable  number  of  I/O  pads.  This 
synchronous  multiplexing  requires  the  overflows  to  be  re-sampled  at  25  MHz,  the 
multiplexed  output  occupying  then  a  50  MHz  bandwidth. 
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The  timing  of  these  conversions  between  the  synchronous  and  asynchronous 
worlds  had  been  very  carefully  checked,  in  order  to  avoid  the  production  of 
spikes  (when  chopping  synchronous  data  to  obtain  an  asynchronous  clock)  and 
setup-hold  timing  violations  or  meta-stable  states  (when  re-sampling  the  output  of 
an  asynchronous  counter). 

3.3  Full  custom  against  standard  cells  in  strategy  #  1 

Only  a  full  custom  design  could  take  advantage  of  the  regular  structure, 
potentially  allowing  very  short  interconnections.  A  short  interconnection  length 
allows  to  build  gates  with  smaller  devices  than  in  the  standard  cell  context, 
leading  to  a  power  saving  [6]. 

The  design  cost  of  a  full  custom  layout  of  the  autocorrelator  is  kept  affordable 
by  the  use  of  N  similar  instances  of  the  "channel  cell",  with  most  of  the  wires 
connected  by  abutment. 

(N  =  64  in  the  first  prototype). 

The  gate  metal  is  used  for  short  wires  inside  the  channel  cell,  reducing  the 
number  of  vias  and  allowing  a  much  more  dense  layout  than  with  standard  cells. 
It  has  been  checked  that  the  resistance  of  these  wires  (max.  150  Ohms)  induces  a 
negligible  delay  (less  than  5  ps). 

A  long  shift  register  is  the  most  sensitive  circuit  when  considering  the  clock 
skew  hazard. 

To  minimize  the  clock  skew,  a  low-impedance  planar  grid  clock  net  was  made, 
driven  by  16  buffers  evenly  spaced  on  the  chip  core.  Such  a  precaution  is 
possible  only  in  a  full  custom  context. 

4.  The  parallel  approach,  or  the  strategy  #  2 

The  idea  :  dividing  by  a  factor  K  the  required  processing  speed,  by  handling  the 
signal  through  K  parallel  paths.  It  is  commonly  admitted  that  the  price  to  pay  in 
this  case  will  be  an  increase  of  the  hardware  complexity  by  a  factor  of  K. 

In  this  context,  we  considered  the  option  of  replacing  the  GaAs  hardware  by 
standard  CMOS,  with  a  "parallelization  factor"  K  between  4  and  8.  (K  is  also 
known  as  "Time  Multiplex  Factor".) 

Before  discussing  the  possible  motivations  that  could  lead  to  retain  this  option, 
let  us  describe  its  implementation. 


4.1  The  high-speed  frond-end 

The  front-end  receives  the  high-speed  data  (nominally  400  Msamples/sec)  and 
produces  a  parallel  flow  K  times  slower,  carrying  the  same  information. 


6 


Figure  4  shows  the 
straightforward 
architecture  of  this  circuit, 
where  each  square  box 
represents  a  couple  of  D- 
type  flip-flops  handling  2 
bits  of  data. 

It  also  produces  the  "slow 
clock"  S^y.  by  dividing  by 
K  the  frequency  of  the 
original  (fast)  sampling 
clock 

This  part  has  to  be  made 
of  high-speed  technology, 
like  ECL  or  GaAs.  It 
represents  a  very  small 
amount  of  logic, 
compared  with  the 
complete  correlator. 

For  this  reason,  standard 
ECL  parts  can  be 
proposed  in  spite  of  their 
power  consumption,  in  the 
other  hand  an  ASIC  is 
not  justified  for  such  a 
simple  piece  of  logic. 


Fig.  4  :  Parallel  solution  front-end 


4.2  The  parallel  correlator  core 


The  architecture  of  the  parallel  core  if  derived  from  the  reference  architecture, 
which  is  the  single  folded-line  system  of  figure  3,  with  the  goal  of 
producing  exactly  the  same  results. 

The  single  folded  delay  line  is  replaced  by  K  parallel  folded  delay  lines, 
clocked  by  the  "slow"  clock  S^j^. 

These  delay  lines  operate  synchronously,  but  carry  images  of  the  original 
signal  sampled  at  instants  separated  by  the  period  of  the  fast  clock  F^j^. 

Each  channel  has  to  contain  K  multipliers,  that  will  work  in  parallel  to 
perform  the  same  amount  of  computation  as  a  single  mutiplier  running  K 
times  faster  did  in  the  reference  architecture.  Each  of  these  K  multipliers  has 
to  process  a  pair  of  samples  with  the  same  time  difference,  characteristic  of 
a  given  channel,  and  these  pairs  are  chosen  in  such  a  manner  that  the 
products  computed  simultaneously  are  the  same  as  those  which  are  processed 
in  sequence  by  the  single  multiplier  of  the  reference  architecture. 

The  K  products  are  added  together  to  feed  the  integrator. 
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Figure  5  shows  an  example  of  interconnections  between  a  channel  and  a  slice  of 
the  K  folded  delay  lines,  in  the  case  K  =  4. 

Attention  is  called  by  the  difficulty  of  representing  such  a  network  on  a 
schematic  diagram.  As  soon  as  the  number  of  represented  channels  exceeds  3, 
the  diagram  becomes  unreadable  (let  us  recall  that  we  propose  a  minimum  of  64 
channels  per  chip).  The  fact  is  that  the  structure  is  still  very  regular,  but  this 
regularity  would  be  manageable  only  on  a  N-dimensions  schematic  diagram  ! 

The  solution  is  to  abandon  the  schematic  diagram,  and  to  take  advantage  of  the 
modem  methods  based  on  HDLs  (Hardware  Description  Languages). 

We  proposed  to  generate  the  parallel  core  by  "procedural  instanciation",  which 
means  that  the  structure  is  described  by  a  construction  algorithm  rather  than  by  a 
2-dimension  graphical  view. 

A  benefit  of  this  method  is  the  "genericity",  allowing  to  change  the  values  of  K 
or  the  number  of  channels  without  having  to  rework  the  circuit  by  hand. 


fig.  5  :  one  channel  inside  the  parallel  core  (K=4) 
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4,3  Full  custom  against  standard  cells  in  strategy  #  2 

The  main  motivation  for  full-custom  design  in  the  case  of  the  GaAs  chip  of 
strategy  #  1  was  the  regularity  of  the  structure,  easily  translatable  into  regular 
masks  layout.  In  the  case  of  strategy  #  2,  the  network  structure  is  very  difficult 
to  implement  by  hand  in  form  of  a  2D  geometry.  Moreover,  a  full  custom 
implementation  of  the  parallel  core  would  lack  flexibility,  locking  the  project  to 
a  specific  value  of  K. 

For  these  reasons,  this  time  the  full-custom  approach  loses. 

The  generic  procedural  generation  fits  better  with  the  automatic  "place- and-route" 
software  that  works  with  a  standard-cells  library. 

Our  preliminary  experiments  showed  that  the  state-of-the-art  place-and-route 
programs,  based  on  a  non-deterministic  optimization  algorithm  (simulated  annealing) 
have  no  difficulty  to  produce  very  compact  layouts. 

5.  Comparison  between  strategies 


The  study  of  strategy  #2  (all-silicon)  was  motivated  mainly  by  the  temporary 
difficulty  to  obtain  GaAs  prototypes  and  some  pessimistic  predictions  about  the 
future  of  this  technology.  In  fact  the  all-silicon  approach  offers  the  advantage  of 
making  the  project  much  more  flexible  in  the  terms  of  relations  with  manufacturers. 
This  flexibilty  is  enhanced  by  the  use  of  procedural  generation  and  automated 
layout,  allowing  to  change  the  foundry  and  to  adapt  the  K  factor  to  the  available 
performances  without  a  lot  of  rework. 

Another  benefit  of  the  all-silicon  approach  is  a  simplification  of  the  instrument 
architecture,  because  the  boundary  between  the  "fast"  part  (GaAs)  and  the  "slow" 
part  (CMOS)  of  the  correlator  dissapears  (see  figure  2).  In  strategy  #2,  these  two 
parts  are  merged  into  one  chip,  and  the  complex  multiplexing  scheme  used 
between  the  fast  chip  and  the  slow  chip  no  longer  exists.  One  may  object  that  a 
new  boundary  appears  between  the  front-end  (ECL)  and  the  correlator  core,  but 
this  boundary  is  much  simpler  to  manage  than  the  previous  one. 

The  all-silicon  approach  has  also  three  major  drawbacks  :  the  difficulty  of 
predicting  the  timing  performances,  the  difficulty  to  predict  the  power  consumption, 
and  the  radiation  sensitivity  of  CMOS.  The  first  difficulty  is  related  with  the 
random  place-and-route,  the  second  one  is  a  characteristic  of  CMOS. 

Let  us  recall  that  GaAs-MESFET  is  appreciated  for  space  application,  because  its 
power  consumption  is  easy  to  predict,  and  it  does  not  produce  latch-up  in 
presence  of  radiations. 
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6.  State  of  the  project 


Started  earlier,  the  strategy  #1  is  more  advanced.  A  first  prototype  of  the  chip 
set  has  been  designed,  manufactured  and  tested  [7],  having  shown  the  feasibility 
of  the  instrument  but  leaving  room  for  many  improvements,  and  an  improved 
version  of  the  GaAs  chip  is  in  the  manufacturing  process. 

Fig.  d  is  a  photograph  of  the  first  GaAs  chip  (area  19.5  nim2)  in  its  special 
high-frequency  ceramic  package. 


fig.  6  :  The  first  GaAs  correlator  chip 


In  the  other  hand,  the  second  strategy  has  not  yet  been  implemented  in  silicon.. 

A  generic  procedural  generation  program  has  been  developed,  producing  structural 
netlists  in  Verilog  format,  that  can  be  imported  in  the  CAD  framework  used  for 
placing  and  routing  the  standard-cells.  A  high  effort  has  been  made  for  verifying 
by  simulation  the  generated  circuits,  by  means  of  automatic  comparison  with  the 
outputs  of  the  reference  circuit. 

But  the  speed  performances  evaluation  and  the  power  consumption  estimation  of 
the  parallel  correlator  are  still  to  be  done. 
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7.  Conclusion 


Two  strategies  are  actually  developed  for  the  space  spectrometer.  The  strategy  #1 
is  presently  prefered,  mainly  because  it  is  the  most  advanced  in  terms  of 
schedule. 

But  such  a  long  term  project  cannot  rely  only  on  a  solution  depending  on  a 
unique  manufacturer,  a  second  source  is  mandatory  ;  and  this  second  source  is 
based  on  strategy  #2 
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Abstract.  Today's  exploding  complexity  of  knowledge  and  much  higher  requirements 
imposed  on  graduates  in  engineering  to  become  market  competitive  is  substantially 
changing  educational  landscape  at  universities  worldwide.  A  vivid  example  of 
encouragement  in  experimentation  with  engineering  curricula  in  search  for  a  new 
equilibrium  in  educational  standards  are  relaxed  requirements  from  the  Accreditation 
Board  for  Engineering  and  Technology  (ABET)  programs  in  the  United  States.  An 
additional  pressure  for  changes  in  education  occurs  due  to  the  availability  of  the 
Internet  and  WWW  resulting  in  distant  learning  and  virtual  classroom  paradigms.  The 
Collaborative  Engineering  experiment  being  developed  at  the  University  of  New 
Hampshire  (UNH)  challenges  a  traditional  curriculum  by  emphasizing  the  need  for 
graduating  managers  with  engineering  background  to  become  team  players  rather  than 
theoreticians  and  design  individualists.  The  curriculum  comprises  educational, 
commercial,  and  governmental  objectives  with  fuzzy  boundaries  among  them.  At  the 
same  time  the  extremely  challenging  tasks  of  practicing  management  team  engineering 
using  advanced  examples  from  science  and  technology  are  addressed  in  the  curriculum. 
The  paper  describes  the  fundamentals  of  the  interdisciplinary  curriculum  in  engineering 
being  implemented  at  the  department  of  Electrical  and  Computer  Engineering  (ECE)  in 
collaboration  with  the  Wittemore  School  for  Business  and  Economics  (WSBE) 
and  the  Institute  for  Study  of  Earth,  Ocean,  and  Space  (EOS).  The  rationale  behind  this 
curriculum  is  driven  by  real  projects  under  study.  The  current  project  in  collaborative 
engineering  is  the  development  of  a  small  scientific  satellite  called  CATSAT 
(Cooperative  Astrophysics  and  Technology  Satellite).  The  emphasis  of  the  presentation 
is  on  its  generality  and  expandability  due  to  a  limited  infrastructure  required  and  tools 
such  as  the  Internet  and  WWW  used  in  the  program. 
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Abstract 

This  paper  first  presents  a  generic  service  to  manage  cooperative  groups  of  agents  and 
to  manage  dynamic  formation  of  subgroups  of  agents  inside  cooperative  groups.  The 
model  used  to  represent  relations  between  groups  of  agents  is  based  on  graphs.  The  struc¬ 
ture  of  the  cooperative  groups  changes  dynamically  in  time  according  to  the  entries  and 
exits  of  the  agents.  The  cooperative  model  has  then  been  applied  inside  teleteaching 
groups.  To  provide  remote  interactions  between  a  student  and  a  teacher,  a  shared  electron¬ 
ic  board  has  been  developed:  it  gives  remote  views  of  applications  shared  through  the 
board  and  offers  remote  control  of  these  applications.  Then,  a  future  integration  of  the 
shared  electronic  board  is  proposed  inside  a  whole  cooperative  class  of  students. 
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1  Introduction 

The  advanced  technologies  based  on  computers  video  processing  are  more  and  more 
applied  inside  the  Computer  Aided  Learning  domain.  The  current  commercial  products 
are  based  on  multimedia  CD-ROM  to  handle  locally  stored  pictures.  Such  CD-ROM 
based  technologies  do  unfortunately  not  support  the  interactions  and  all  the  data  exchang¬ 
es  that  can  happen  inside  a  whole  classroom:  they  have  been  first  developed  either  to  learn 
alone  in  front  of  a  computer  or  inside  a  classical  classroom  with  the  help  of  a  teacher. 

To  realize  distributed  or  virtual  classrooms  in  which  the  students  and  the  teacher  are 
not  geographically  located  in  the  same  place,  several  tools,  supported  by  high  speed  mul- 


through  the  network.  Before  being  displayed,  their  contents  is  analysed  an  mixed  as  if 
they  were  slides.  The  two  drawings  are  then  superimposed.  There  is  however  no  remote 
interaction  allowed  by  the  system:  the  teacher  can  not  directly  help  the  student  and  can 
not  modify  his  work. 

The  shared  board  presented  in  this  paper  is  based  on  the  exchange  of  videos  that  con¬ 
tain  the  views  of  the  shared  applications  with  the  possibility  of  remotely  controlling  them. 


3  Group  model  for  teleteaching 

The  model  used  was  proposed  by  Diaz  [DIAZ92].  Each  agent  has  a  set  of  data  for 
which  it  is  the  sole  owner;  no  other  agent  can  modify  the  data.  When  an  agent  modifies 
its  data,  it  sends  the  new  value  to  the  other  agents  that  need  this  data  to  realize  the  coope¬ 
rative  work. 


3.1  Dynamic  cooperative  groups 

A  cooperative  group  is  composed  of  agents,  organised  to  define  the  relations  between 
the  members  of  the  group.  The  structure  of  the  cooperation  is  represented  by  a  directed 
graph,  the  cooperation  graph,  as  shown  in  Figure  1 .  Vertices  represent  the  agents,  edges 
represent  the  relations  between  them.  Thus,  an  edge  from  agent  “T”  to  “S”  means  that  “T” 
can  read  some  or  all  of  the  values  owned  by  “S”,  as  shown  in  Figure  2.  The  approach  re¬ 
tained  for  cooperation  is  those  of  information  sharing  between  agents  [KAPL92].  Agent 
“S”  cooperates  with  agent  “T”  if  it  gives  or  shares  some  of  its  information  with  “T”. 
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The  cooperation  graph  defines  a  structural  type,  the  conceptual  structure  of  the  coop¬ 
eration.  This  structure  can  be  described  in  terms  of  a  compound  activity,  composed  of  the 
types  of  the  cooperating  entities,  the  types  of  information  they  are  allowed  to  read  and  the 
types  of  information  they  allow  other  agents  to  read,  together  with  a  relation  between  the 
involved  cooperating  entities. 

Let  us  now  consider  how  these  activities  are  initiated.  The  trivial  solution  corresponds 
with  the  case  where  cooperation  is  considered  to  begin  when  all  entities  are  ready  to  start. 
Of  course,  this  view  is  too  restrictive  as  cooperative  work  can  be  performed  as  soon  as  an 
adequate  and  sound  set  of  participants  come  into  existence.  This  means  that  at  a  given  in¬ 
stant  it  is  not  necessary  that  all  agents  are  present  to  start  or  conduct  the  cooperative  work. 
As  a  consequence,  the  conceptual  model  is  extended  to  define  which  agents  must  cooper¬ 
ate  to  execute  the  cooperative  work. 


The  application  associated  to  the  cooperative  group  has  to  define  the  subsets  of  agents 
which  have  a  meaning  for  the  implementation  of  the  cooperative  work.  In  fact,  if  a  picto¬ 
rial  representation  is  considered,  these  allowed  subsets  of  agents  form  subgraphs  of  the 
cooperation  graphs.  Among  all  subgraphs  of  the  graph  of  cooperation,  the  application 
chooses  those  that  are  semantically  possible.  The  subgraphs  retained  by  the  application 
are  called  valid  instantaneous  graphs.  Figure  3  shows  an  example  of  two  valid  instantane¬ 
ous  graphs  that  could  come  from  the  cooperation  graph  of  Figure  1 . 
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3.2  Cooperation  service  and  protocol  description 

The  proposed  service  manages  the  dynamicity  of  the  cooperative  groups  defined 
[VILL95]  and  aims  to  pass  from  a  valid  configuration  where  agents  are  cooperating  to  an¬ 
other  one,  in  considering  the  requests  of  entry  in  cooperation  and  the  requests  to  leave  co¬ 
operation  coming  from  the  agents.  Let  us  consider  a  set  of  agents  which  are  cooperating 
and  which  constitute  a  valid  instantaneous  graph.  Inside  the  cooperative  group,  other 
agents  may  want  to  participate  to  the  cooperative  work  and  join  those  which  are  already 
working.  Also,  agents  which  are  cooperating,  may  want  to  leave  the  work  and  stop  their 
participation  in  the  cooperation.  Considering  the  requests  to  enter  and  the  requests  to 
leave  the  cooperative  work,  the  service  tries  to  form  a  new  valid  instantaneous  graph. 

Several  cases  are  possible  to  take  the  decision  of  changing  the  cooperation  configura¬ 
tion.  The  first  one  is  to  change  each  time  when  possible.  The  service  which  manages  the 
cooperation  realizes  the  modification  as  soon  as  it  is  possible.  The  second  one,  which  has 
been  selected  here,  considers  the  decision  modification  as  a  cooperative  decision.  As  a 
consequence,  the  opportunity  of  changing  cooperation  is  proposed  to  the  actual  set  of  co¬ 
operating  agents.  The  cooperating  agents  vote  to  accept  or  to  deny  the  configuration 
change. 

The  service  for  changing  the  cooperation  structure  requires  four  different  phases  to 
manage  the  interferences  between  data  exchanges  and  the  cooperation  structure  change. 
When  a  cooperation  change  has  been  decided,  the  new  cooperating  agents  must  exchange 
their  own  initial  contexts  in  following  the  cooperation  structure.  The  second  phase  is  those 
of  the  realization  of  the  cooperative  work  where  agent  exchange  data  when  they  change 
their  values.  The  third  one  appears  before  terminating  a  cooperation,  i.e.  before  changing 
a  cooperation  structure:  the  data  manipulated  by  the  agents  must  reach  a  coherent  state. 
The  last  one  corresponds  to  the  restructuring  of  the  cooperation 

The  proposed  service  has  been  formally  described  (Figure  4)  using  the  formal  descrip¬ 
tion  technique  Estelle  [ISO9074],  [BUDK87].  An  Estelle  specification  consists  of  a  set  of 
modules,  each’s  behaviour  defined  by  a  finite  state  automaton.  To  communicate  and  ex¬ 
change  information  between  the  modules,  bidirectional  first-in-first-out  queues  are  used. 
The  formal  description  architecture  is  based  on  the  Open  System  Interconnection  layer 
model.  Users,  which  represent  the  cooperative  agents,  are  connected  to  modules  which 
provide  the  service  to  participate  in  a  cooperative  group.  The  execution  of  these  modules 
is  the  protocol  which  provides  the  service.  The  cooperation  manager  module  supervises 
the  evolution  in  time  of  the  cooperative  group.  All  the  protocol  modules  are  connected  to 
another  module  which  provides  a  multicast  service.  These  specifications  have  been  used 
to  simulate  and  test  our  service. 

The  Estelle  code  of  the  protocol  modules  and  of  the  manager  has  been  reused  for  an 
implementation  on  top  of  a  UNIX  platform  [VILL95].  Each  Estelle  module  instance  has 
been  included  inside  a  UNIX  process  that  have  been  distributed  across  an  Ethernet  net¬ 
work.  The  UNIX  distributed  processes  implement  a  generic  cooperative  group  member¬ 
ship  service. 
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Legend: 
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Channel  for  control  information  of  cooperation. 

Channel  for  data  transmissions  of  cooperative  work. 

Channel  interface  between  a  user  and  the  service. 

Channel  to  receive  requests  to  participate  or  leave  the  cooperation. 
Channel  to  manage  evolution  of  cooperation. 

Service  Access  Point  of  the  dynamic  membership  cooperation 
service. 


3.3  Modelling  teleteaching  groups 

The  generic  previous  cooperative  model  has  been  applied  to  model  various  teleteach¬ 
ing  configurations.  Inside  such  groups,  the  teacher  has  a  central  position  (Figure  1).  The 
students  hear  the  teacher’s  speech  and  they  see  his  documents  required  for  the  course 
(slides,  drawings,  notes...).  The  cooperative  graph  for  a  course  forms  a  star  whose  center 
is  the  teacher  agent,  edges  being  directed  into  the  central  position  of  the  star. 

For  global  discussions  between  the  whole  class,  each  cooperative  agent  must  see  the 
informations  of  all  the  members  of  the  group.  Such  situations  require  fully  connected  co¬ 
operative  graphs. 

In  the  case  of  practical  work,  the  cooperative  teleteaching  group  of  Figure  1  can  be  re¬ 
tained.  Students  have  to  make  exercises  in  their  own  environments.  They  can  not  commu¬ 
nicate  between  them  to  avoid  copying.  The  teacher  must  have  access  to  each  student’s 
context  to  supervise,  help  or  respond  to  their  questions.  The  teacher’s  help  can  consist  in 
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a  simple  teacher/student  dialog  but,  can  be  composed  of  a  direct  remote  modification  of 
the  student’s  context  made  by  the  teacher  and  supported  by  tools  as  a  shared  electronic 
board. 

Inside  a  course,  to  describe  more  interactive  situations,  the  teacher  can  take  into  ac¬ 
count  the  students’  feedback  (concentration  of  the  students  or  questions  coming  from 
them).  In  this  case,  he  must  know  and  see  the  own  informations  of  the  students.  This  co¬ 
operative  group  is  depicted  by  Figure  1  too.  When  students  ask  questions,  they  can  influ¬ 
ence  the  teacher’s  context  with  his  agreement  in  remotely  pointing  or  clicking  to  the  sub¬ 
ject  of  their  comments.  For  instance,  if  a  student  does  not  understand  a  particular  point  of 
a  drawing  made  by  the  teacher,  he  remotely  points  the  unclear  part  of  the  drawing  while 
he  asks  his  question.  Such  a  functionality  is  taken  into  account  inside  shared  electronic 
board  applications. 

All  the  valid  configurations  of  a  course  or  a  practical  work  contain  the  teacher.  Some 
variants  can  appear  inside  the  choice  of  the  valid  configurations:  a  graph  is  valid  when  at 
least  the  teacher  and  one  student  are  present,  or  when  at  least  the  teacher  and  a  fixed 
number  of  students  are  here...  The  teacher  alone  accepts  or  denies  the  change  of  a  current 
valid  configuration. 

The  interactive  course  configuration  has  been  used  to  describe  the  functionalities  of  the 
proposed  synchronous  cooperative  shared  electronic  board. 


4  Shared  electronic  board 


4.1  Presentation 

Work  presented  in  this  section  describes  a  generic  tool  for  remotely  sharing  various 
multimedia  applications.  A  majority  of  multimedia  computer  aided  learning  applications 
include  digitized  video  sequences  to  detail  or  to  illustrate  several  important  parts  of  a 
course. 

As  an  illustrative  example,  training  pilots  and  maintenance  staffs  are  made  inside  air¬ 
craft  industries  in  using  a  Computer  Aided  Learning  System  (CALS)  that  contains  video 
sequences.  When  a  trainee  presses  a  button  inside  the  aircraft  cockpit  drawing,  the  system 
displays  other  graphics  to  explain  the  functioning  of  an  electrical,  electronic  or  hydraulic 
circuit,  this  functioning  being  strengthened  by  the  display  of  a  live  video  sequence.  To 
learn  all  the  complex  procedures  required  to  maintain  or  pilot  an  aircraft,  pilots  and  main¬ 
tenance  staffs  use  CALS  and  are  supervised  by  an  instructor.  The  trainees  and  the  instruc¬ 
tor  directly  dialog  because  they  are  located  in  the  same  classroom.  Now,  let’s  suppose  that 
all  the  members  of  the  class  are  not  located  in  the  same  place  and  are  geographically  dis¬ 
tributed:  to  communicate  and  to  exchange  information  between  them,  the  group  members 
need  workstations  connected  to  a  network.  Moreover,  the  distributed  information  ex¬ 
changes  are  only  possible  if  tools  that  ensure  remote  dialogs  (as  visioconferences)  and  re¬ 
mote  interactions  or  control  are  available:  a  distributed  electronic  board  is  then  useful  to 
share  the  access  of  applications  owned  by  the  instructor  or  the  trainees. 
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The  shared  electronic  board  can  be  directly  applied  to  the  sharing  of  a  CALS  that  runs 
on  the  instructor’s  workstation.  To  emphasize  the  functionalities  of  the  electronic  board 
(Figure  5),  the  following  situation  has  been  ehosen: 

-  a)  The  instructor  owns  the  CALS  that  runs  locally  on  its  workstation.  Through 
the  electronie  board,  it  broadcasts  the  current  picture  (that  corresponds  to  the  cur¬ 
rent  state  of  the  application).  Then,  all  the  trainees  show  the  picture  of  the  in¬ 
structor’s  CALS. 

-  b)  During  the  course,  a  student  asks  for  a  question.  When  the  instructor  agrees, 
a  remote  pointer  controlled  by  the  requested  trainer  appears  inside  the  instruc¬ 
tor’s  board.  This  pointer  helps  the  trainee  to  explain  and  to  show  the  unclear  cur¬ 
rent  displayed  parts  of  the  CALS  application.  The  instructor  has  given  to  the 
trainee  the  pointing  right  on  its  electronic  board. 

-  c)  For  more  complete  discussion  or  explanations,  the  instructor  can  give  to  the 
requesting  trainee  the  remote  control  right  of  all  the  applications  viewed  inside 
the  electronic  board;  in  our  example,  the  local  instructor’s  CALS  is  then  remote¬ 
ly  controlled  by  the  trainee.  This  can  be  useful  if  the  question  concerns  precise 
points  that  require  the  CALS  running.  While  the  trainee  asks  his  question,  it  con¬ 
trols  the  CALS. 
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Figure  5.  Functionalities  of  the  shared  electronic  board. 
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Each  member  of  the  group  owns  a  board  inside  its  local  screen.  A  local  board  is  com¬ 
posed  of  a  window  that  contains  views  of  the  shared  applications.  The  board  of  the  in¬ 
structor  and  those  of  the  trainees  dialog  between  them  to  synchronize  their  local  views  of 
the  applications  and  to  ensure  the  remote  interactions  between  a  trainee’s  board  and  the 
instructor’s  board. 

To  share  and  show  a  view  of  an  application,  the  instructor  slides  inside  the  electronic 
board  window  the  window  application.  Any  application  that  the  instructor  owns  can  be 
shared  through  the  electronic  board.  A  trainee  sees  a  view  of  the  shared  application  inside 
its  local  board. 

To  obtain  the  pointing  right,  a  trainee  puts  its  pointer  inside  its  local  board.  Then,  once 
the  right  has  been  given  by  the  instructor,  two  independent  pointers  appear  on  the  instruc¬ 
tor’s  and  trainees’  boards,  the  first  one  belonging  to  the  requested  trainee,  the  second  one 
belonging  to  the  instructor.  Each  member  controls  the  position  of  its  own  pointer.  The  ap¬ 
plications  shared  inside  the  board  remain  to  the  control  of  the  instructor. 

In  the  remote  control  case,  only  one  pointer  remains  inside  the  boards.  The  instructor 
gives  the  remote  control  right  to  one  of  its  shared  applications  to  a  trainee.  The  authorized 
trainee  remotely  controls  with  this  unique  pointer  the  chosen  application.  When  the  train¬ 
ee  has  finished  his  speech,  the  instructor  takes  the  application  control  again. 

At  a  given  instant,  at  most  one  person  controls  the  shared  applications:  either  the  in¬ 
structor  or  an  authorized  trainee. 


4.2  Realization 

The  first  implementation  developed  has  been  simplified  and  supports  only  interactions 
between  the  instructor  and  a  single  trainee. 

4.2.1  Platform  description 

The  implementation  platform,  depicted  on  Figure  6,  is  composed  of  two  Sun  Sparcsta- 
tions  equipped  with  a  Sun  audio  card  and  a  Parallax  video  card.  The  audio  card  records 
and  plays  back  sounds  in  the  PCM  format.  Pictures  can  be  digitized  from  two  different 
video  inputs,  displayed,  compressed  and  uncompressed  in  real  time  with  the  JPEG  com¬ 
pression  algorithm  by  using  the  video  card. 

A  10  Mbps  Ethernet  local  area  networks  is  available  inside  this  platform  which  pro¬ 
vides  sufficient  throughput  for  this  kind  of  application. 
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4.2.2  Electronic  board  characteristics 

The  first  video  input  of  the  instructor’s  workstation  is  used  by  his  shared  electronic 
board  and  pictures  coming  from  this  source  are  displayed  in  the  background  of  the  board, 
the  shared  applications  being  displayed  in  the  foreground.  The  background  pictures,  as  the 
shared  applications,  are  displayed  inside  the  trainee’s  board.  This  first  video  input  is  con¬ 
nected  to  a  table  camera  used  to  grab  papers,  slides,  or  any  other  object  displayed  to  the 
remote  boards.  With  this  additional  functionality,  the  shared  electronic  board  is  well  suit¬ 
ed  to  display  classical  conferences  supports  to  the  trainees. 

The  second  video  input  is  not  used  by  the  electronic  board  application,  and  can  serve 
for  other  video  applications  as  a  visioconference  (with  the  connection  of  a  camera). 

The  information  exchanges  between  two  boards  are  mainly  based  on  video  transmis¬ 
sions:  all  the  contain  of  the  instructor’s  board  (background  video  and  shared  application 
window)  is  grabbed,  digitized  and  sent  to  the  remote  trainee’s  board.  Only  a  view  of  the 
running  shared  applications  is  sent  to  the  trainee.  This  choice  has  been  made  for  several 
reasons: 

-  There  is  only  a  local  copy  of  the  running  applications  (that  is  easier  to  maintain 
and  to  change  than  several  distributed  copies). 

-  Multimedia  applications  as  Computer  Aided  Learning  Systems  require  a  lot  of 
disk  space  for  storing  the  multimedia  data.  Distributing  a  copy  of  the  application 
to  each  trainee  could  not  be  conceivable.  So,  the  application  is  only  stored  inside 
the  instructor’s  computer. 

-  The  synchronisation  problems  between  the  application  views  sent  are  easier  to 
manage. 

The  main  problem  of  sending  videos  is  the  rate  required  by  the  application.  This  prob- 


10 


lem  is  nevertheless  limited  with  the  use  of  compression  technics  that  often  efficiently  de¬ 
crease  the  amount  of  data  to  be  transmitted.  In  the  case  of  very  low  bandwidth  networks, 
the  hypothesis  of  distributing  the  shared  applications  code  has  been  considered  and  only 
the  events  for  the  application  running  are  exchanged.  The  copies  of  the  shared  application 
must  evolve  synchronously  and  must  all  receive  the  same  events  in  the  same  order.  As  a 
consequence,  these  environments  as  SharedX  [HPSH91]  require  complex  algorithms  to 
rearrange  all  the  receiving  events  before  being  executed  by  the  copies  of  the  applications. 


The  communications  between  the  remote  electronic  boards  are  based  on  top  of  the 
UDP/IP  protocol  that  ensure  the  rate  needed  for  video  transmissions. 

The  application  boards  for  the  instructor  and  for  the  trainee  have  been  developed  using 
the  C  language,  and  they  use  the  Sun  multithreading  mechanism  with  lightweight  proc¬ 
esses  to  solve  the  synchronisation  needs  of  the  concurrent  threads.  Indeed,  inside  each 
board,  several  data  flows  have  to  be  synchronized  (for  instance  the  current  position  of  the 
pointers  and  the  display  of  pictures)  before  being  presented.  Each  board  is  composed  of 
1500  lines  of  C  code  and  contains  2  threads  for  each  mode,  the  first  one  for  receiving  the 
data  from  the  network,  the  other  one  for  displaying  synchronously  the  data. 


Figure  7  gives  the  data  flow  between  the  instructor’s  board  and  the  trainee’s  board.  In 
the  three  functioning  mode,  the  image  of  the  electronic  board  is  always  sent  from  the  in¬ 
structor  to  the  trainee.  When  the  pointing  mode  is  activated,  the  trainee’s  pointer  coordi¬ 
nates  are  sent  to  the  instructor’s  board.  During  the  remote  control  mode  activation,  the 
trainee’s  pointer  coordinates  and  all  the  local  events  created  inside  the  trainee’s  applica¬ 
tion  using  the  views  of  the  application  are  sent  to  the  instructor’s  board. 

Remark:  if  the  window  of  a  shared  application  is  not  completely  included  inside  the 
instmctor’s  board,  only  the  included  part  is  transmitted  inside  the  video  and  received  by 
the  trainee’s  board. 
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Figure  7.  Data  flow  between  a  trainer  and  a  trainee. 
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4.3  Future  work:  a  cooperative  shared  electronic  board 

The  next  step  of  our  work  is  to  extend  the  electronic  board  to  a  whole  class  of  trainees. 
This  requires  to  take  into  account  the  cooperative  structure  of  the  group  and  its  possible 
dynamicity.  As  a  consequence,  the  general  cooperative  service  and  the  extended  shared 
board  have  to  be  integrated.  The  proposed  general  architecture  is  depicted  in  Figure  8. 


Architecture  for  a  Central  group 

group  member  manager 


Figure  8.  Architecture  of  the  cooperative  electronic  board. 


The  integration  of  the  shared  electronic  board  and  the  cooperation  membership  is  done 
at  the  application  level  defined  on  top  of  the  cooperation  layer.  The  cooperative  users  are 
connected  to  the  cooperative  service.  They  request  to  enter  or  to  quit  the  cooperative 
group  and  they  inform  the  electronic  board  module  of  the  group  structure  modifications. 
The  cooperation  protocol  and  the  cooperation  manager  define  the  cooperative  service  and 
they  together  manage  all  the  modifications  of  the  cooperation.  The  electronic  board  part 
ensure  all  the  functionalities  of  the  cooperative  board.  The  new  electronic  board  modules 
are  now  connected  to  a  multicast  service  to  communicate  the  board  data  to  all  the  coope¬ 
rative  members.  Moreover,  the  new  electronic  board  of  the  instructor  must  take  into  ac¬ 
count  several  requests  that  could  come  from  the  trainees. 
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5  Conclusion 


This  article  has  first  presented  a  general  model  to  represent  cooperative  services,  then 
has  described  a  generic  service  that  manages  the  dynamicity  of  these  cooperative  groups. 
A  shared  electronic  board  application  useful  in  a  context  of  a  teleteaching  environment 
has  been  presented  followed  by  the  proposition  of  a  future  integration  of  the  membership 
service  and  the  board  application. 

The  cooperative  membership  service  has  then  been  implanted  using  a  centralized  man¬ 
ager.  To  improve  the  robustness  of  the  protoeol,  current  work  aim  to  distribute  the  group 
management  responsibility  in  considering  the  cooperation  manager  as  a  special  token  that 
circulates  among  the  cooperative  agents. 

The  point  to  point  realization  of  the  electronic  board  is  now  asymmetric:  the  function¬ 
alities  of  the  instructor  are  different  of  those  of  the  trainees.  A  direct  extension  could  be 
to  consider  a  symmetric  board:  the  trainee  can  access  to  the  instructor’s  context  and,  if 
necessary,  the  instructor  could  access  to  a  trainee’s  context  in  the  case  of  practical  works. 
In  the  same  way,  inside  the  electronic  board,  the  access  to  the  diverse  contexts  of  the  train¬ 
ees  allow  the  instructor  to  supervise  the  whole  group  and  to  help  some  of  them  if  neces¬ 
sary. 

At  end,  the  electronic  board  has  to  be  integrated  inside  a  complete  teleteaching  envi¬ 
ronment  that  contains  a  visioconference  to  support  the  informal  dialogs  between  the  mem¬ 
bers  of  the  group,  the  subjects  of  the  discussion  being  shared  using  the  electronic  board. 
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Abstract:  Economical  constraints  such  as  maintenance  cost  reduction  required  the 
introduction  of  a  new  architecture  to  design  systems  which  will  be  embedded  in  the 
future  commercial  aircrafts.  This  architecture  called  "Integrated  Modular  Avionics" 
leads  to  a  new  approach  of  system  design.  In  particular  this  architecture  allows  multiple 
applications  to  be  integrated  on  one  framework.  Moreover,  as  studied  systems  concern 
the  avionics  domain,  dependability  must  be  considered  as  a  major  property  of  these 
systems.  During  the  European  BRITE-EURAM  project  "IMAGES  2000",  the  main 
European  aircraft  manufacturers  and  suppliers  and  some  research  laboratories  worked 
together  to  study  the  means  and  the  process  which  must  be  used  to  design  dependable 
Integrated  Modular  Avionics  systems.  In  this  paper,  we  analyse  the  characteristies  of  the 
Integrated  Modular  Avionics  systems  to  highlight  that  the  obtaining  of  dependable 
systems  will  require  a  special  effort  on  specification  step  from  the  part  of  the  engineers 
involved  in  the  design  of  the  systems  embedded  in  the  future  planes. 

Keywords:  specification,  dependability,  avionics,  embedded  systems.  Integrated 
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Modular  Aviomcs. 

1.  Integrated  Modular  Avionics  systems 

In  traditional  architectures,  the  avionics  functions  are  embedded  in  Line  Replaceable 
Units  (LRUs).  Each  LRU  is  an  item  of  equipment  dedicated  to  only  one  avionics 
function.  It  is  designed  completely  (i.e.,  in  particular,  it  needs  its  hardware  resources) 
and  is  completely  removed  in  case  of  failure.  With  the  Integrated  Modular  Avionics 
(IMA)  concept,  a  framework,  specific  to  the  avionics  requirements,  provides  all  the 
resources  (for  processing,  I/O,  power  supply,  etc.)  needed  by  the  avionics  applications. 


*  I  would  like  to  thank  Rene  Meunier  who  works  at  Aerospatiale,  for  his  contribution  to 
this  paper. 

^  This  paper  stems  from  a  part  of  INSA  and  Aerospatiale  participation  in  the  European 
Brite-Euram  project  "Images  2000"  sponsored  by  the  European  Union. 
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The  second  originality  of  the  IMA  concept  concerns  the  implementation  of  the 
framework.  The  cabinets  composing  the  framework  are  divided  into  several  types  of 
modules:  power  modules,  core  modules,  I/O  modules  and  a  gateway  module.  The 
cabinets  communicate  by  using  a  multi-transmiters  network  (aircraft  bus). 

The  ARINC  651  standard  highlights  these  two  aspects  in  the  definition  of  the  IMA 
concept; 

•  firstly,  it  is  modular:  within  cabinets,  standardised  modules  provide  all  the  required 
resources  and  communicate  through  a  standardised  backplane  bus.  As  these  modules 
are  the  basic  components  for  maintenance,  they  are  named  Line  Replaceable 
Modules  (LRMs); 

•  secondly,  avionics  are  integrated:  this  means  that  each  IMA  platform  receives  several 
numbers  of  avionics  functions.  Its  resources  are  thus  shared. 

The  Integrated  Modular  Avionics  concept  will  allow: 

•  multiple  avionics  applications  to  be  produced  by  different  suppliers  and  integrated  on 
one  platform; 

•  the  modules  to  be  designed  independently  to  the  functions. 

There  are  economical  interests: 

•  for  the  airliners:  mainly  the  reduction  of  the  maintenance  costs  because  there  are  no 
one  different  hardware  by  function  but  the  functions  share  standardised  IMA 
platform  including  standardised  modules; 

•  for  aircraft  manufacturers  and  equipment  suppliers  because  it  is  not  necessary  to 
design  again  the  resources  which  are  necessary  to  execute  the  functions. 

2.  Importance  of  specification  step  in  IMA  context 

2.1  Introduction 

In  one  sub-task  of  the  "Images  2000"  project,  we  studied  at  what  moment  in  the 
software  system  life  cycle,  faults  are  introduced.  Moreover  we  tried  to  evaluate  the  rate 
of  the  faults  introduced  at  each  step.  This  study  was  not  specific  to  IMA  systems  but 
concerns  any  software/hardware  application.  The  goal  of  this  study  was  to  signal  the 
development  steps  on  which  efforts  must  be  focused  to  avoid  the  presence  of  faults  in 
any  software/hardware  systems. 

This  study  showed  that  numerous  faults  included  in  software  do  not  come  fi-om 
problems  associated  with  design  and  programming  phases  but  are  due  to  a  bad 
expression  of  client's  requirements  as  specifications.  The  rate  of  30%  of  the  faults  is 
provided  by  [7].  This  rate  value  is  also  given  by  other  authors  [1].  These  studies  concern 
general  software/hardware  systems,  that  is  they  are  not  specific  to  avionics  area.  In 
reality  this  value  is  higher.  Indeed,  at  each  design  step,  the  designer  must  express  the 
specifications  of  entities  (components,  functions,  data,  etc.)  which  will  be  designed  in 
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the  next  step.  The  designer  is  therefore  his  or  her  own  client  [14].  Thus,  he  or  she 
introduces  additional  faults  during  design  step  which  are  however  relative  to 
specification  activity.  For  instance,  [6]  and  [3]  quoted  that  25%  of  the  faults  occurring 
during  the  design  phase  correspond  to  problems  associated  with  the  interfaces  of 
components  used  during  this  phase.  Other  pieces  of  information  reinforce  this  opinion: 
[17]  specifies  that  30%  of  the  faults  come  from  the  fact  that  the  limit  values  of  data  or 
the  states  not  frequently  reached  are  badly  taking  into  account  by  the  designers.  This 
value  is  higher  for  systems  for  which  interactions  with  hardware  or  software 
components  are  numerous.  For  instance  [15]  presents  a  control  software  in  which  56% 
of  the  faults  are  coming  from  problems  of  interfacing  with  software  components  (36%) 
or  hardware  components  (20%).  So,  certain  characteristics  of  the  developed  systems 
may  lead  to  the  increasing  of  the  number  of  the  faults  due  to  erroneous  specifications. 
Importance  of  component  interactions  is  one  of  these  characteristics  which  exists  in 
particular  in  IMA  systems. 

In  the  following  sub-sections  we  will  present  five  characteristics  of  the  IMA  systems 
(multiple  partners,  multiple  domains,  multiple  interactions,  complexity  of  the 
behaviours,  maintenance)  showing  both  the  requirements  and  the  difficulties  to  obtain 
correct  specifications.  These  characteristics  therefore  increase  the  risk  of  presence  of 
faults  in  specification  documents.  So  this  paper  concludes  that  important  effort  will  be 
required  on  specification  elaboration  to  obtain  dependable  IMA  systems. 

2.2  Multiple  partners 

The  IMA  concept  requires  multiple  plane  manufacturers  and  suppliers  to  work  together 
in  order  to  design,  produce  and  maintain  hardware  and  software  systems  embedded  in 
planes.  Such  a  cooperation  previously  existed  between  European  manufacturers  for 
instance  for  the  Airbus  aircrafts.  However  it  was  not  so  strong  because  each  of  them  had 
to  develop  separate  and  (relatively)  independent  parts  of  the  control  system  embedded  in 
the  planes.  Now,  the  IMA  concept  requires  the  sharing  of  common  resources 
provided  by  the  framework,  then  it  implies  a  strong  integration  of  the  developed 
elements  and  therefore  a  strong  inter-dependency  between  the  partners.  It  is  expressed  in 
[10]  as  follows:  "Equipment  suppliers  are  no  longer  delivering  pieces  of  hardware  and 
software  which  operate  as  a  complete  unit.  Mostly  they  supply  software  units  which 
need  to  be  integrated  with  other  units,  probably  by  a  third  part,  before  being  complete". 
Such  a  sharing  exist  at  applications  levels  (sharing  of  the  platform)  but  also  at  module 
levels  (modules  must  cooperate)  and  at  the  level  of  the  components  of  each  module. 

For  instance  firstly  [11]  defines  the  resources  shared  by  a  core  module  (processor, 
memory,  backplane  bus,  operating  system,  etc.).  Consequently,  the  expression  of  the 
precise  specifications  of  the  IMA  components  or  modules  is  absolutely  necessary 
because  persons  of  various  companies  will  have  to  share  IMA  resources  to  develop  their 
parts  of  the  global  system  elements. 
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Secondly,  multiple  partners  have  also  to  work  together  due  to  the  modularity  of  the 
framework  structure.  Indeed  the  framework  is  split  into  modules  cooperating  to  provide 
the  global  service  offered  by  the  framework. 

The  existence  of  multiple  partners  is  also  the  cause  of  the  first  difficulty  to  obtain 
specifications.  On  one  hand  each  firm  has  one  proper  way  and  means  to  express  its 
specifications;  this  concerns  the  style  of  the  specification.  On  the  other  hand  numerous 
pieces  of  information  are  considered  as  implicitly  known  (they  belong  to  the  culture,  i.e. 
the  basic  knowledge,  of  the  company  memberships);  this  concerns  the  contents  of  the 
specifications. 

To  conclude  this  first  aspect:  on  one  hand,  multiple  partners  have  to  work  together  to 
design  applications  sharing  common  resources,  so  they  require  common  specifications 
of  the  framework;  on  the  other  hand,  multiple  partners  have  to  work  together  to  design 
components  cooperating  to  provide  the  services  of  the  IMA  framework,  therefore  they 
also  require  common  specifications,  now  for  these  components. 

2.3  Multiple  domains 

Concerning  the  IMA  framework  design,  an  original  structure  was  chosen.  The  cabinets 
which  compose  the  framework  are  split  into  modules  cooperating  to  provide  the  global 
framework  services.  The  originality  comes  from  the  fact  that  these  modules  are  not 
associated  with  functional  parts  but  resources.  Then,  the  IMA  framework  cabinets 
contains  one  or  several  of  the  following  modules:  power  supply  module,  core  module 
which  provide  computation  resources,  I/O  module  for  external  communication  needs 
and  gateway  module  for  bus  plane  communication  needs.  The  second  characteristics  of 
IMA  systems  is  thus  the  presence  of  several  technological  domains.  Due  to  the  required 
cooperation  of  multiple  partners,  the  designers  must  understand  the  concepts  of  these 
domains,  without  being  a  specialist  For  instance  the  following  four  considered  types  of 
modules  concern  four  domains: 

•  Power  Supply  module  requires  knowledge  in  electricity  and  uses  the  associated 
terminology; 

•  Core  module  deals  with  process  management  and  so  handles  terms  such  as 
"synchronisation",  "scheduling",  etc.; 

•  I/O  module  explanation  assumes  knowledge  on  OSI  layer  model; 

•  Gateway  module  treats  of  one  more  subject. 

So  the  expression  of  the  specifications  of  IMA  modules  is  necessary  to  allow  people 
working  in  various  domains  to  cooperate.  However,  a  person  working  on  one  domain  is 
not  able  and  does  not  have  to  know  detailed  information  on  the  technology  used  in  other 
domains.  However  he  or  she  has  to  possess  a  complete  knowledge  on  the  behaviour  of 
the  other  elements  of  an  IMA  platform,  that  is  on  their  abstract  specifications. 
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So,  the  presence  of  multiple  domains  at  the  same  time: 

•  requires  the  existence  of  abstract  specifications  allowing  concepts  to  be  handled 
without  knowledge  on  their  technological  implementation; 

•  makes  difficult  the  production  of  these  specifications  because  it  does  not  authorise 
assumption  of  implicit  knowledge  as  it  is  frequently  assumed  by  the  persons  working 
on  the  same  domain. 

2.4  Multiple  interactions 

Another  characteristics  of  IMA  architecture  is  the  strong  interactions  between  the 
elements  (modules  or  components)  and  also  with  the  applications.  All  the  IMAGES 
2000  reports  specify  numerous  relationships  between  these  elements. 

In  the  IMAGES  2000  project,  the  interactions  are  at  first  required  by  the  definition  of 
the  functions  of  the  IMA  elements:  evident  interactions  exist  between  the  I/O  module 
and  the  core  processing  modules  because  the  I/O  modules  aim  to  interface  physical 
signals  and  logical  events  and  data  processed  by  other  modules.  The  definition  of  the 
Health  Monitoring  role  gives  another  example  of  interaction  requirements.  "The  Health 
Monitor  distributes  information  about  the  failures  of  the  components  to  other 
components  (...)  The  Heath  Monitor  consists  of  a  distribution  and  a  membership  part" 
[9].  Numerous  other  interactions  between  elements  may  be  signalled:  intra  cabinet 
communication  and  inter  cabinet  communication,  communication  between  the  Health 
Monitor  and  the  Core  module  for  reconfiguration  or  to  communicate  information  about 
the  state,  etc. 

The  interactions  are  also  due  to: 

•  the  choice  of  a  distributed  implementation  instead  of  a  centralised  one.  An  example 
is  the  distribution  of  the  error  handling:  the  detection  is  done  in  various  components 
(processor,  executive,  application)  but  also  provokes  reactions  in  other  parts  (local 
health  monitoring,  leader  health  monitoring).  Another  example  concerns  the  core 
module:  for  instance  the  synchronisation  management  may  require  communication 
protocols  between  components; 

•  the  implementation  of  fault  tolerance  mechanisms.  For  example,  the  replication  of 
elements  requires  the  communication  of  information,  for  instance  to  compare  the 
data  produced  by  several  versions  (N-versions  technique).  In  particular  to  confine  the 
occurrence  of  the  errors  in  order  to  master  their  effects,  the  system  must  be  split 
(concept  of  segregation).  The  interactions  of  the  introduced  parts  must  then  be 
specified.  Another  example  is  the  health  monitoring.  In  order  to  have  the  monitoring 
of  errors  in  one  location,  the  occurred  errors  must  be  communicated  to  the  health 
monitor; 

•  the  implementation  of  abstract  services.  This  reason  conducted  for  example  to  the 
partitioning  of  the  Core  software  and  the  introduction  of  the  HIS  (Hardware  Interface 
System)  "which  maps  the  logical  requests  made  by  the  executive  onto  the  particular 
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physical  configuration  of  the  core  module"  [9].  In  the  same  way  APEX  interface  was 
introduced  which  creates  a  splitting  into  several  elements  and  then  interactions 
between  them  (see  ARINC  653).  Another  example  is  the  "logical  communication 
object"  [12]  used  to  communicate  between  the  Local  Health  Monitoring  and  the 
Leader  Health  Monitoring  and  called  "port"  in  the  ARINC  653  document.  Let  us  note 
that  definitions  of  abstract  services  allow  also  specifications  which  are  independent 
to  implementation  technology  (hardware  or  software,  centralised  or  distributed  to  be 
defined  as  previously  required. 

On  the  opposite,  the  previous  facilities  make  difficult  the  definition  of  specifications. 
For  instance,  the  abstract  definition  of  the  inter-partition  communication  hides  the 
means  used  to  implement  the  real  communication.  For  one  way  used  to  communicate, 
the  required  time  may  be  defined.  However,  this  way  could  change  dynamically:  "for 
example,  two  partitions  may  communicate  over  the  intra-cabinet  bus,  or  even  over  the 
inter-cabinet  bus,  in  one  configuration,  but  may  be  reconfigured  to  communicate  while 
on  the  same  core  module.  (...)  The  end  result  is  that  the  transmit  time  of 
communications  might  be  widely  varying  in  some  situations,  but  the  computer  must 
accommodate  this"  [11].  This  last  sentence  implies  that  communication  time  must  be 
specified  by  an  interval  [Tmin,  Tmax]  and  not  by  one  value  T. 

The  specification  of  the  interactions  between  IMA  elements  composing  the  platform  is 
specially  important  and  complex  because  the  controls  of  interactions  are  not 
conventional.  For  instance,  there  are  not  hierarchical  relations  between  elements  as  it 
exists  for  sequential  systems  (sub-program  interaction  model).  Moreover  due  to  the 
segregation  requirements  (in  particular  the  faults  occurring  in  an  element  must  have  no 
effect  on  the  behaviour  of  another  one),  all  the  possible  interactions  must  be  mastered 
(no  hidden  interactions). 

Specifications  of  the  available  interactions  between  the  IMA  platform  and  the  IMA 
applications  are  also  required.  A  reference  manual  defining  the  IMA  platform 
specifications  must  be  written. 

Numerous  authors  showed  that  the  number  of  faults  generally  increases  when  the 
number  and  the  complexity  of  the  interactions  between  components  increase.  These 
faults  may  concern  the  interface  [3]  [6]  or  the  behaviour,  such  as  states  not  frequently 
reached  and  therefore  badly  taking  into  account  [17].  So,  in  order  to  obtain  a  dependable 
IMA  system,  the  interactions  of  the  modules  and  between  the  platform  and  the 
applications  must  be  mandatory  well  specified. 

2.5  Complexity  of  the  behaviour 

Another  characteristics  of  the  IMA  system  is  the  complexity  of  the  behaviour  of  the 
components.  Indeed  the  numerous  interactions  induce  numerous  internal  states  and  thus 
numerous  different  cases  of  behaviour. 

To  reduce  complexity  of  a  system,  the  specification  of  its  behaviour  is  frequently  split. 
For  instance  to  define  the  Process  Scheduler,  the  project  [11]  had  proposed  to  split  it 
into  several  elements:  process  identification,  semaphore  management,  event 
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management,  buffer  management,  process  queue  management,  time  and  scheduling 
management.  However  each  group  of  services  cannot  be  specified  independently  in  a 
simple  way  because  correlations  between  the  groups  exist.  For  instance  when  an  event 
occurs  (event  management  service)  to  resume  a  waiting  task,  the  queue  management 
module  is  called  (the  task  goes  from  the  queue  of  the  waiting  processes  to  the  queue  of 
the  ready  processes).  So  the  complexity  of  the  behaviour  of  the  numerous  services  of  the 
components  carmot  be  handled,  examining  each  service  one  by  one,  independently  to 
others. 

Unfortunately,  numerous  studies  showed  that  the  increasing  of  an  application 
complexity  implies  the  increasing  of  the  number  of  faults  [1],  [2],  [8],  [16],  particularly 
due  to  erroneous  specifications.  So  complexity  is  another  reason  needing  to  pay  a 
special  attention  to  the  specification.  In  practice,  the  behaviour  of  the  framework  as  well 
as  the  ones  of  the  modules  will  be  relatively  simple  to  obtain  the  mastering  of  the  IMA 
systems. 

2.6  Maintenance 

Finally  the  IMA  architecture  aiming  to  facilitate  the  maintenance  by  changing  elements, 
the  specifications  of  these  elements  are  very  important  because  they  define  the 
interoperability  of  the  elements  and  then  their  interchangeability.  This  aspect  concerns 
multiple  technological  means:  mechanics,  hardware  connection,  electrical  compatibility, 
hardware  and  software  communication,  operational  means  (hardware  and  software 
operating  system),  etc. 

In  particular  the  definition  of  interchangeability  criteria  requires  the  specification  of 
numerous  temporal  information.  For  instance  a  study  [10]  dealt  with  time  constraints  for 
temporal  segregation.  Let  us  signal  that  we  highlighted  in  another  project  the  difficulties 
to  specify  this  kind  of  temporal  pieces  of  information  [13]. 

Another  aspect  concerns  the  error  handling.  The  IMA  architecture  requires  the 
communication  of  the  detected  errors  to  the  health  monitoring  [12]  for  a  maintenance 
objective.  Thus,  the  interchangeability  criteria  includes  the  specification  of  the  errors 
which  may  be  transmitted.  The  definition  of  an  exhaustive  list  of  errors  is  not  easy 
because  some  of  them  depend  on  the  design  choices  or  the  technological  choices  used  to 
implement  the  component. 

To  facilitate  the  maintenance,  the  specified  elements  must  be  generics  as  possible. 
Moreover,  the  "good"  level  of  standardisation  must  be  chosen. 

3.  Conclusion 

In  this  paper  we  did  not  describe  any  solution;  we  just  highlighted  problems.  However, 
the  given  information  may  be  used  to  provide  three  pieces  of  advice. 

First  and  foremost  common  means  must  be  shared  by  aircraft  system  designers 
intervening  in  the  development  of  IMA  systems  to  handle  specifications.  This  is 
necessary  to  take  the  five  described  characteristics  into  account.  These  means  concern: 
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expression  languages,  tools  (for  checking  the  completeness,  etc.)  and  methods  (to 
produce  specification  expressions). 

The  second  advice  concerns  the  common  methodology  used  to  specify  IMA  elements. 
The  designers  of  IMA  elements  must  be  warmed  about  the  great  risk  of  fault 
introduction  in  the  specifications  due  to  the  type  of  the  system  to  be  developed.  To 
highlight  this  warning,  the  giving  of  the  values  resulting  from  the  references  previously 
quoted  must  be  communicated  to  these  designers.  Thus  the  engineers  will  perceive  the 
necessity  to  use  seriously  the  languages,  tools  and  methods  which  will  be  proposed. 

The  work  to  be  done  to  write  the  specifications  may  be  long.  This  moment  is  often 
perceived  (for  a  part)  as  lost  time  which  will  provoke  delays  in  the  project  schedule.  In 
fact  it  saves  time.  Indeed  studies  show  that,  if  all  the  faults  introduced  in  the 
development  of  a  software  tool  (what  ever  are  their  origins)  multiply  the  costs  by  two, 
the  same  studies  also  signal  that  the  correction  cost  of  a  fault  due  to  bad  specification  is 
100  as  many  expensive  than  the  cost  of  the  studies  of  the  specifications  which  would 
allow  the  detections  of  the  fault  to  be  obtained  [4]  [5].  So,  the  use  of  the  techniques 
proposed  to  avoid  faults  in  IMA  components  specifications  will  cost  time  and  therefore 
money  but  less  than  if  they  are  not  used. 

The  bad  perception  of  the  work  to  be  done  to  obtain  the  specifications  comes  from  the 
fact  that,  at  first,  the  managers  often  focus  on  the  system  disposal  and  after  on  its 
quality.  On  the  opposite,  in  Japan,  the  obtaining  of  a  consensus  between  the  client  and 
the  designer  is  very  important;  then  this  phase  may  be  long.  [18]  gives  two  examples  of 
two  big  software  applications  for  which  the  specification  expression  and  the  preliminary 
studies  consume  60%  (first  example)  and  70%  (second  example)  of  the  time  necessary 
to  obtain  the  software  tools.  He  quotes  that  this  long  work  then  allows  a  very  quick 
design  and  programming.  This  short  time  is  due  to  the  fact  that  the  designers  were 
impregnated  with  the  client  application  domain. 

So,  the  third  advice  to  be  included  in  the  common  methodology  used  to  specify  IMA 
elements  is  the  following  one:  the  IMA  project  managers  must  be  warmed  about  the 
importance  of  the  requirements  specification  phase.  The  use  of  means  to  obtain 
dependable  specifications  costs  money  but  saves  more.  To  highlight  this  warning,  the 
giving  of  the  values  resulting  from  the  references  previously  quoted  must  be 
communicated  to  these  managers. 
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Abstract  :  The  aim  of  this  communication  is  to  explain  cooperation  agreement  as  a 
specific  mode  of  coordination  and  to  study  how  this  agreement  relation  is  emboded  into 
organisational  knowledge  and  competences.  In  a  first  part,  we  propose  a  definition  of  the 
motivations  for  cooperation.  The  second  part  deals  with  cooperation.  This  last  guides 
responses  to  the  unanticipated  technological  change  using  «  trust  ». 
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1  Introduction 

By  cooperation  we  mean  any  king  of  coordination  as  a  objective  choice  from 
agents,  conscious  to  create  an  interelation. The  aim  of  this  communication  is  to  explain 
cooperation  agreement  as  a  specific  mode  of  coordination  and  to  study  how  this 
agreement  relation  is  emboded  into  organisational  knowledge  and  competences.  In  a  first 
part,  we  propose  a  definition  of  the  motivations  for  cooperation.  The  second  part  deals 
with  cooperation.  This  last  guides  responses  to  the  unanticipated  technological  change 
using  « trust ». 

2  A  definition  of  and  motivations  for  cooperation 

This  part  is  dedicated  to  the  identification  and  understanding  of  the  specificity  of 
cooperation.  Therefore,  we  have  to  explain  the  proper  mecanisms  of  this  type  of 
coordination.  The  analysis  of  various  databases  and  works  dedicated  to  this  subject 
already  let  us  design,  as  we  will  explain  it  later  on  that  whatever  their  forms  (ffanshising, 
joint  venture),  cooperations  keep  the  identity  of  each  one  of  the  partners,  on  the  contrary 
of  integration.  They  must  be  equitable  to  be  stable  in  time,  through  the  obtention  of 
mutual  advantage  which  does  not  imply  that  cooperation  involves  partners  of  the  same 
weight.  Those  three  criteria  then  allow  to  precisely  specify  the  kind  of  cooperation  and 
to  distinguish  them  from  the  other  forms  of  interfirms  relations. 

The  nature  of  industrial  cooperation  is  linked  to  acknowledgement  of  concerted 
sharing  division  of  labor  between  the  firms.  Thus,  by  essence,  this  raises  the  question  to 
render  itself  dependent  faced  with  an  other  firm,  or  even  a  competitor,  which  to  be 
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justifiable  requires  a  higher  profit  than  the  one  procured  by  internalisation.  Also,  to 
survive,  cooperation  must  rely  on  equitable  partition  of  the  benefits.  Comitment  and 
profit  evaluation  not  only  requires  an  efficient  control  and  evaluation  system  but  also  the 
development  of  one  organisational  equilibrium  and  a  long  term  strategy.  Consequently, 
we  can  wonder  what  are  the  original  motivations  of  the  choice  of  cooperation.  This 
question  joins  the  question  of  dynamic  efficiency  that  must  conciliate  resources  creation 
and  organisational  flexibility. 

2.1  Nature  and  Dilemma  of  cooperation 

Throughout  cooperation,  firm  seeks  externalysing  a  part  of  its  activities  to 
reduce  the  constraint  caused  by  its  productions  and  innovations  (due  to  the  presence  of 
set  up  costs).  These  last  alleviate  the  flexibility  and  capability  of  reactions  of  the  firm 
faced  with  environmental  changes. 

2.1.1  Industrial  Cooperation  Nature  :  coordination  of  dissemblable  activities 

The  question  of  activities  coordonation  using  a  strategy  other  than  the  one  of 
the  market  or  internalisation,  joins  the  question  of  the  nature  of  industrial  cooperation. 
Promoved  by  firms,  partenariatships  are  based  on  the  notion  of  capability  of  one 
organisation  to  mobilise  its  competencies  in  order  to  develop  productive  processes.  This 
notion  of  capabilities[19]  allows  to  explain  why  the  firm  coordonites  different  activities. 
The  activities  diversity  used  by  firms  leads  them  to  select  those  that  they  pratice 
according  to  the  caracteristics  of  the  required  capabilities  for  their  implementation.  The 
capabilities  cover  at  the  same  time  the  formalised  objective  knowledge  and  experience, 
fhiit  of  learning.  Thus  RICHARDSON  distinguishes  the  same  activities  from  the  one  that 
are  complementary  [20]. 

The  same  activities  are  those  that  use  the  same  capabilities  in  term  of  knowledge 
and  experiencies  for  their  realisation  inside  the  firm.  Complementary  activities  can 
represent  various  phases  of  production  processes  and  therefore  they  require  to  be 
efficiently  coordonated.  «  ...that  activities  are  complementary  when  they  represente 
different  phases  of  a  process  of  production  and  requiere  in  some  way  or  another  to  be 
co-ordinated  »[20].  This  activities  coordonation  principle  then  leads  to  unite  the  same 
and  complementary  activities  into  the  firm,  not  similar  but  complementary  activities  being 
coordonated  by  cooperation.  Partnership  corresponds  to  one  work  division  between  the 
firms  for  which  «  the  root  of  cooperation  agreements  seems  to  be,  in  fact,  that  partners 
agree  of  obligation  degree  and  devote  to  assurance  degree  for  the  respect  of  futur 
behavior  »  [8].  Then,  cooperation  exists  if  two  or  more  organisations  agree  on  a  ex-ante 
production  strategy.  This  allows  then  to  coordonite  their  complementary  but 
dissemblable  activities  (quantitatively  and  qualitatively).  The  aspect  of  volontary  ex-ante 
coordination  is  important  in  the  way  that  it  devotes  conscious  effort  to  reach  together  a 
collectively  fixed  goal.  But  this  choice  is  not  riskless. 
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2.1.2  Dilemma 

To  cooperate  is  not  an  innocent  behavior  but  it  is  based  on  a  dilemma.  The 
adoption  of  one  cooperation  is  a  strategy  that  relies  on  delicate  choice  :  to  ally  with  a 
rival  or  not  implies  to  limit  future  opportunities.  The  firm  must  manage  activities  by 
specialisation,  integration  or  diversification,  keeping  at  the  same  time,  an  internal 
organisational  equilibrium,  measured  throughout  flexibility.  « In  its  largest  meaning 
flexibility  translates  the  possibility  for  a  manager  to  be  able  to  consider  at  anytime  once 
again  his  choices  in  order  to  maintain  the  optimality  of  his  decision  [2].  Faced  with  an 
organisational  choice,  where  coordination  can  be  carried  out  using  alliance  or 
internalisation,  this  puts  forward  the  question  of  loss  or  maintain  of  future  possibilities,  in 
other  words  the  question  of  choice  between  static  or  dynamic  flexibility  compared  to  the 
environment  of  the  firm.  Thus,  the  static  flexibility  depends  on  the  existence,  at  a  given 
time,  of  a  set  of  more  or  less  important  number  of  opportunities.  The  aim  of  the  firm  is  to 
constitute  an  optimal  range  of  products.  The  use  of  cooperation  strategy,  that  joins  the 
choice  of  an  external  coordination  of  activities,  can  facilitate  this  goal  by  cost  repartition 
among  partners.  FORAY  [8]  points  out  that  when  coordination  depends  on  interfirms 
cooperation,  it  is  then  possible  to  allocate  sunk  cost  amongst  several  organisations. 
Cooperation  allows  then  to  release  a  double  contraint : 

-  to  decrease  the  sunk  cost  linked  to  the  investisments, 

-  to  develop  the  specificities  (human  resources)  either  by  adaptation  or  by 
integration  of  technology. 

But  the  firm’s  behavior  can  have  a  static  position  by  the  answer  aspect  of  the 
firm’s  behavior.  However  the  interest  of  the  choice  of  cooperative  strategies  seems  to  be 
more  interesting  for  the  implementation  of  an  initiative  behavior.  Because  environmental 
firms  changes,  these  last  must  try  to  anticipate  changes  in  order  to  have  a  more  efficient 
capability  of  reaction.  Thus,  the  dynamic  of  organisation  relies  on  contradiction  between 
the  integration  necessity  and  resource  association  to  give  them  specific  (technology 
creation  condition)  and  the  necessity  to  put  them  on  the  market  (reversibility  condition) 
[8].  This  compromise  takes  as  much  importance  as  the  environment  of  the  firm  is 
pertubed  (strong  uncertainty)  under  the  effects  of  the  technological  development.  The 
choice  to  prefer  an  internal  coordination  to  the  external  one  then  implies  the  question  of 
the  dynamic  efficiency. 

2.2  Dynamic  Efficiency  question 

Cooperation  strategy’ choice  is  for  the  firm  a  complex  problem  because  it  is 
linked  to  the  notion  of  dynamic  efficiency  in  other  words  the  capacity  of  the  firms  to 
create  new  resources  keeping  environmental  dynamic  flexibility.  In  this  case,  cooperation 
is  a  difficult  but  advantagous  solution. 

2.2.1  To  create  new  resources 

Cooperation  choice  is  often  viewed  by  the  firms  as  a  loss  of  freedom  towards  its 
competitors.  This  is  the  raison  why  from  an  internal  organisation’s  point  of  view  the 
capacity  of  the  firm  to  create  and  develop  new  resources  is  linked  to  the  notion  of 
competencies  as  firm’ core  business  that  enable  it  to  preserve  its  comparative  advantage. 
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Then,  a  first,  extention  carries  out  by  the  strategic  management  developed  it-self  with 
WILLIAMSON’S  works  on  internalisation  linked  to  the  notion  of  assets  specificity  in 
order  to  over  come  its  failures  concerning  the  integration  of  innovation  and  technical 
change.  RUMELT  [22]or  example,  defines  the  firm  as  a  capabilitie  or  unique  resources 
serial,  combined  in  order  to  accordate  itself  to  the  demand  changes.  But,  other  authors, 
in  an  evolutionist  trend  using  learning  phenomena,  explain  dynamic  efficiency  using 
learning  processes.  From  that  moment,  organisation  structuration  is  not  longer  the  cost 
minimisation  but  the  possession  by  firm  of  specific  competences  and  rules.  «  The 
organisational  firm’s  essence  is  linked  to  the  basic  competencies  that  it  has  in  other 
words  a  set  of  technological  competences  complementary  assets,  rules,  that  identify  the 
firm  in  a  given  activity  »  [10].  Then  firm’s  core  business  is  strategic  core  of  the  firm.  This 
is  the  raison  why  «  a  basic  competence  is  a  set  of  technical  differentiated  compentences, 
complementary  assets,  and  rules,  that  altogether  form  the  basis  of  currential  capabilities 
of  a  firm  in  a  particular  activity.  ..  Typically,  such  differencies  have  a  major  underlying 
dimension  that  renders  the  imitation  by  the  other  difficult  even  impossible  »  [10].  These 
authors  defend  the  idea  that  a  distinction  between  complementarity  competences  (that 
may  be  externalised)  and  crucial  competences  (that  firm’s  core  business  allows  to 
maintain  a  internal  coherence  of  the  organisation).  The  organisational  goal  is  more, 
today,  to  produce  specificities  than  to  develop  products.  But,  the  increasing  uncertainty 
makes  difficult  this  goal  realisation  as  the  organisational  learning,  sources  of 
modifications  of  knowledge  and  rules  can  also  be  a  destabilising  tool  for  the 
organisation.  For  COHENDET  and  LLERENA[2],  « this  is  an  implementation  of 
localised  learning  processes  that  constitute  the  most  adequate  organisational  answer  for 
the  viability  of  an  organisation.  If  organisational  learning  is  likely  to  explain  the 
difficulties  of  the  activity  coordination  for  internal  organisation  or  alliances,  it  may  be 
significative  of  dynamic  flexibility  in  order  to  answer  to  the  question  of  efficiency. 

2.2.2  To  develop  a  dynamic  flexibility 

In  order  to  keep  its  internal  coherence,  managing  the  organisational  internal 
coherence  compromise,  the  firm  develops  cooperation  strategies  in  order  to  find  an 
equilibrium  between  internal  and  external  coordination  of  its  activities.  But,  in  this 
context,  it  is  not  longer  a  static  but  a  dynamic  flexibility.  This  capability  to  continously 
react  in  the  time,  to  environmental  variation  will  be  implemented  generated  by  the 
external  environment  or  by  the  capability  to  improve  future  choices.  In  the  case, 
organisational  flexibility  is  dynamic  because  it  develops  knowledge  accumulation 
processes.  According  to  FAVEREAU[6],  it  is  this  capacity  of  stimulation  and  orientation 
of  learning,  capability  that  have  or  that  can  have  organisation  in  order  to  maintain  or  to 
increase  the  possibility  to  react  at  the  change.  To  stress  the  importance  of  environmental 
uncertainty  is  the  same  as  to  ask  why  complexity  and  irreversibility  management  are 
objectives  of  the  firm.  Complexity  and  irreversibility  are  united  by  the  introduction  of 
uncertainty  in  the  analysis.  According  to  AMIT  and  SCHOMAKER  [1],  managerial 
decisions  must  take  into  account  uncertainty  (technological,  competitor’s  behaviors  and 
customer’s  preferences),  relational  complexity  (competitive  interactions)  and  inter- 
organisational  conflicts.  These  three  conditions  leverage  decision  making  of  individuals 
and  their  important  choice.  Irreversibility  is  one  of  the  most  important  caracteristic  of 
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decision  making  in  a  non  probabilisable  uncertainty  and  more  generally  speaking  one 
aspect  of  the  phenomena  linked  to  the  devlopment  of  innovations.  More  precisely, 
environment  generates  complexity  and  uncertainty  due  to  three  sources  of  possible  non 
probabilisable  uncertainty  ;  innovation,  others  agent’s  behavior  and  environment  it-self 
Cooperation,  then  is  a  form  of  organisation  that  allows  partners  to  reduce  those 
disruptions.  By  its  organisational  mode,  more  flexible  and  independant  of  the  major 
organisation,  it  is  an  organisation  form  that  manages  interface  with  the  environment.  In 
other  words,  it  carries  out  a  test  (for  new  products,  new  technologies  and  new  partners). 
Cooperation  agreements  create  compatibility  area.  Thus,  they  are  particulary  useful  for 
idiosyncratic  resources  merger  with  an  important  tacite  constraint.  Depending  on 
propriety  of  loose  coupling,  interdepedencies  are  strong  inside  the  system  and  these  are 
weak  inside  intersystems.  Consequently,  this  explains  the  cooperation  caracteristics  as  an 
organisational  form  allowing  to  the  firm  to  develop  new  organisational  forms  with  out 
bringing  disruptions  inside  them.  Cooperation  is  partners  association  in  a  more  flexible 
setting  that  it  is,  for  example,  the  one  of  the  firm. 

Thus,  cooperation  manages  uncertainty  and  complexity  keeping  the  own 
identity  of  partners  and  allowing  the  assimilation  innovations  (product  but  also  the  most 
organisational),  once  functioning  rules  are  routinised.  It  then  becomes  obvious  that 
cooperation  stake  is  the  proces  learning  elaboration  and  the  development  of  rules.  As  LE 
BAS[13]  says  as  the  firm  is  a  learning  laboratory,  cooperation  agreement  can  be 
considered  as  an  experimentation  field. 


3  Cooperation  Dynamic 

Cooperation  evolution  puts  foward  two  important  points :  organisational 
learning  and  trust.  The  following  hypothesis  discussed  is  ;  organisation  learning  among 
partners  is  an  indispensable  tool  for  a  good  evolution  in  the  time  of  the  cooperation 
relation.  It  develops  itself  among  voluntary  agreements,  that  are  contratualised  or  not.  It 
is  a  support  of  trust  built  during  partership,  because  if  learning  exists  during  cooperation, 
actors  win  mutual  assurance  by  better  mutual  knowledge  with  exchange,  using  also  rules 
and  mutual  habits.  From  that  point,  we  can  consider  it  as  an  specific  asset,  in  other  words 
as  an  output  of  relation.  We  propose  to  precise  the  notion  of  organisational  learning 
before  linking  it  with  the  trust  one. 

3.1  Creation  and  Development  of  organisational  learning 

Learnings  depend  on  a  great  part  on  the  nature  of  accumulation  knowledge  and 
the  way  knowledge  is  developed.  «  In  these  conditions,  technology  is  not  a  public  good, 
but  it  implies  specific  knowledge,  idiosyncratics,  partly  approppriable,  that  are 
accumulated  in  the  time  throughout  learning  processes,  specific  too,  whose  the  top 
managers  depend  on  the  proper  knowledge  of  firms  and  technologies  already  used  ». 
Then,  we  will  precise  knowledge  caracteristics  and  their  influences  on  organisation. 
« Search  activity,  and  much  more  again  the  one  of  development,  leads  to  an 
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accumutation  process  by  knowledge,  learning  and  how-know  that  is  not  completly 
formalised  and  come  withing  individual  or  collective  pratices  »  [11].  Usually,  we  agree  to 
reconize  the  following  technological  innovation  caracteristics :  « Technological 

innovation  is  process  that  lasts  differently  according  to  industries.  Morever  it  is  strongly 
localised,  tacit,  path  dependent  and  it  has  irreversible  process  caracteristics  »  [3], To 
understand  the  stake  that  constitutes  the  organisational  learning  creation  for  the 
cooperation  choice  viability  supposes  to  reconize  two  caracteristics  of  knowledge  :  tacit 
and  cumulative  aspects.  Therefore,  the  tacit  aspect  of  internal  rules  of  a  firm  can  be  such 
as  a  firm,  trying  to  imitate  its  concurrent,  will  have  the  most  important  difficulties  to  do 
it,  if  the  firm  has  no  access  to  those  rules.  From  then,  the  organisational  context  is 
fundamental.  The  boundary  between  explicit  and  tacit  knowledges  is  given  by  the 
practice  and  the  strategies  developed  by  the  actors.  So,  the  organisational  change  is 
strongly  linked  to  innovation.  If  for  KANTER,  innovation  is  a  process  allowing  to  find 
new  concrete  solutions  in  the  firm,  MEZIAS  and  GLYNN  [15]  define  innovation  as  a 
discontinuous,  non  daily  and  significative  organisational  change.  This  is  the  reason  why, 
the  implementation  of  new  organisational  structures  must  rely  on  confidence,  reciprocity, 
in  other  words  it  has  to  be  coordinated  by  cooperation.  The  importance  of  interactions 
between  individuals  plays  a  major  part. 

The  tacit  feature  of  knowledge  puts  forward  the  necessity  of  a  stabilised  frame 
in  order  to  favour  the  repeating  and  hereby  the  acquiring  of  codes  to  preserve  the 
knowledges  but  also  the  necessary  components  of  their  diffusion. 

According  to  DOSI,  TEECE  and  WINTER,  «  what  has  been  learnt  during  a 
period  relies  on  what  was  learnt  during  past  periods »  [4].  The  accumulation  aspect  of 
learning  is  fundamental  at  the  individual  and  organisational  level  to  yield  past 
experiences.  Therefore,  there  is  learning  when  the  technical  change  can  be  considered  as 
a  result  or  a  step  in  the  following  building  process,  that  is  to  say  a  regulating  process 
improving  the  existing  technical  solutions  at  technology  structure  of  unchanged  basis  » 
[18].  However,  the  cumulative  aspect  outlines  also  the  fact  that  :  «the  output  of 
researches  is  not  only  today  a  mere  new  technology  but  also  the  submition  of 
knowledges  and  this  output  constitutes  the  basis  of  new  blocks  to  be  used  tomorrow  » 
[16].  Learning  is  irreversible  and  justifies  the  choice  of  cooperative  strategies.  LE  BAS 
and  ZUSCOVITCH[23]  define  the  path  of  learning  depending  on  each  firm,  as  the 
combination  of  internal  and  external  learning  and  the  technological  way  as  the 
configuration  of  those  paths.  From  then,  the  accumulative  part  of  learning  is  to  structure 
the  firm.  Coming  from  its  cumulative  feature,  a  localised  feature  can  be  given  to 
knowledge.  As  a  matter  of  fact,  we  know  the  importance  of  tacit  and  accumulation  (and 
its  accumulation  mode  inside  the  organisation)  when  building  a  knowledge.  The 
importance  of  the  organisational  structure,  of  the  information  system  and  the  way  of 
taking  decision  render  the  combining  ressources  mode  as  a  major  tool  in  the 
development  of  specific  knowledge.  «  The  organisational  choices  are  very  localised  and 
path  dependent,  throughout  the  game  of  organisational  learning  effects  that  they  imply 
and  by  the  specific  investments,  equipment  or  not  that  they  mobilize  ».  This  is  the  reason 
why  interaction  between  partners  takes  a  unique  feature. 
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This  explains  why  the  implementation  of  cooperations  in  the  R-D  field  requires 
a  sharing  and  a  stable  organisation.  As  matter  of  fact,  in  the  cooperation  forms,  the 
elements  that  will  lead  to  the  identification  of  cooperation  will  be  :  confidence  and 
organisational  learning  as  an  output  of  this  kind  of  relations. 


3  .2  .  About  confidence 

We  can  wonder  what  is  the  part  played  by  confidence  whose  importance, 
according  to  empirical  surveys  and  theorical  works,  makes  it  as  a  key  component  of 
cooperations  and  interindividual  cooperations.  Is  this  notion  a  necessary  condition  to 
justify  the  choice  of  a  cooperation  strategy  ?  How  can  it  influence  partnership  ? 

The  notion  of  confidence  is  ambiguous  because  as  an  immaterial  good  it  relies 
on  the  notion  of  reciprocity.  If  as  LUM)VALL[14]says  its  material  root  is 
interdependancy,  it  appears  that  the  reciprocal  aspect  is  present  in  the  organisational 
learning,  developing  itself  inside  the  interaction.  Therefore,  in  a  first  part  we  have  to  put 
forward  the  confidence  and  learning  links  resulting  from  reciprocity  and 
interdependancies.  We  propose,  in  a  second  part  to  underline  their  role  in  the 
cooperations.  This  allows  to  justify  according  to  us  the  choice  of  a  cooperation  strategy. 

3.2.1  Confidence  as  an  active  tool  resulting  from  apprenticeship 

In  order  to  demonstrate  how  this  specific  asset  is  linked  to  learning,  we  must 
remind  ourselves  that  confidence  is  not  material  and  has  no  constraints.  Assimilated  to  an 
implicit  object  non  formalised  between  the  actors,  it  is  defined  as  the  subjective  attitude. 
Its  role  is  to  increment  the  quality  of  technological  creations  localising  at  the  same  time 
apprenticeship  and  the  know-how.  Its  feature  of  specific  good  comes  from  the  particular 
relations  between  partners  as  a  unique  product  of  a  relations  requiring  time.  As  a  specific 
asset,  confidence  minimises  today  and  future  transaction  costs,  but  it  especially  has  a 
reciprocity  feature  between  partners  [17]  interest  that  we  called  organisational  learning. 
However  this  last  does  not  only  imply  a  technical  knowledge  but  also  integrates  a 
common  know-how  knowledge.  This  combination  of  knowledge  has  a  reciprocity 
relation.  Confidence,  relying  on  reciprocity  gives  the  opportunity  to  go  on  instead  of  the 
hypothesis  according  to  which  cooperation  can  be  seen  as  a  specific  organisation  and 
coordination  mode.  As  a  matter  of  fact,  confidence  behaves  as  a  self-reinforcement  of 
the  implementation  of  partnership.  The  interdependancy  of  the  actors,  building  new 
knowledge,  generates  at  the  same  time  knowledge  and  confidence.  «  Confidence  is 
essential.  It  is  not  surprising  to  see  that  it  is  the  cooperation  tool.  We  note  two  main 
ways  at  the  creation  of  cooperation  :  (1)  to  develop  long-term  relations,  (2)  to  try  to 
modify  the  game,  acting  on  four  variables  (rewarding  of  cooperation,  opportunism  gains, 
punition  and  naive  pay-off)  keeping  in  mind  the  importance  of  the  future  »  [9].  What  first 
influences  the  choice  of  a  cooperation  strategy  can  be  featured  by  reputation  effects. 
This  last  compensates  an  ex-ante  confidence  failure,  even  its  non  existence.  If  we  add  the 
part  of  the  learnings  in  the  obtention  of  a  dynamic  organisational  equilibrum,  we  can  then 
put  forward  the  hypothesis  that  the  confidence  linked  to  learning  is  one  of  the  stabilising 
elements  of  the  choice  of  cooperation  as  strategy.  If  confidence  is  a  specific  asset 
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resulting  from  the  interaction  between  partners,  the  organisational  learning  allows  to 
reinfoce  its  development. 

3.2.2  Trust  and  organisational  learning  as  partnership  bases 

The  tacit,  irreversible  and  localised  aspects  of  knowledge,  allowing  to 
encompass  the  difficulties  met  during  the  memorazing  and  development  of  learning 
processes  reveal  the  importance  of  people’s  interactions.  From  then,  coordination  by 
cooperation  is  a  conceptual  frame  that  allows  to  analyse  the  objectives  of  the 
organisational  learning,  that  is  to  say  the  developments  of  knowledge  and  confidence. 

In  this  context,  firms  add  various  knowledge  for  the  mergers.  LORANGE  and 
ROOS  make  the  hypothesis  that  a  partnership  has  for  objective  to  gather  competences. 
One  of  the  goal  is  then  to  « learn  from  an  other  partner  how  to  realise  a  complex 
work»[21].  The  key  feature  of  success  for  a  cooperation  is  in  those  conditions  the 
creation  of  the  organisational  learning.  Therefore,  cooperation  is  not  a  stage  towards  the 
integration  because  actors  make  advantage  of  the  fact  to  develop  a  distinct  cooperation 
of  their  own  organisation.  We  propose  in  fact  this  causality  to  be  inversed.  The 
affirmation  of  an  identity  is  done  throughout  the  time,  although  the  subject  (firm  or 
individual)  changes.  Moreover,  if  the  identity  is  a  social  output,  the  cooperation  claims 
the  identity  of  partners  inside  its  interaction.  It  inforces  their  belonging  and  their  roots  in 
the  society.  The  functioning  components  of  cooperation  relies  on  the  organisational 
flexibility  and  on  its  ability  to  develop  common  knowledge.  The  organisational  learning 
of  cooperation  joins  the  building  of  habits  and  rules  inside  an  organisation,  thus  the 
ability  to  solve  new  problems  produced  by  the  instability  of  the  environment  and/or  its 
behaviors  towards  other  agents.  The  organisational  flexibility  is  the  ability  to  adapt  itself 
to  the  unknown  environment  and  the  one  to  allow  the  organisation  to  maintain  its 
coherence.  Organisations  managed  according  to  cooperation  rules  are  dispositions  faced 
to  the  various  unknown  sources  and  complexity. 

4  Conclusion 

As  it  introduced,  concerning  its  specificity,  cooperation  is  based  on  confidence 
rules,  specific  asset  resulting  from  the  interaction  of  partners  and  on  the  development  of 
organisational  learning.  Cooperation  organisation  is  the  product  of  actors’  strategies  in 
order  to  create  a  basis  for  the  development  of  knowledge  and  learning.  But  the  bilateral 
to  multilateral  field  reinforces  this  conclusion  in  the  way  that  the  reciprocity  system  is 
more  needed  in  the  pertubed  and  unknown  environments. 
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